引用上一次“拉”或“合并”之前的头部状态。
引用上一次“拉”或“合并”之前的头部状态。
提问于 2018-03-15 06:22:07
我发现我经常这样做。
- 运行
git pull或git pull --rebase - 查看标准输出以查看更改。 发自github.com:foo/bar 3d8749e..b795f99 ->主源/母版
- 将此版本范围复制到 git日志-p 3d8749e..b795f99
我想知道是否有一种方法可以指定“最后一次拉或合并之前的HEAD状态”，这样我就可以始终运行相同的命令。
git log -p HEAD@{before pull}..HEAD简单地始终使用HEAD@{1}是关闭的，可能对git pull起作用，但对git pull --rebase不起作用，因为这会将多个条目添加到重触发器中：
$ git reflog
4111cc6 (HEAD -> master) HEAD@{0}: rebase finished: returning to refs/heads/master
4111cc6 (HEAD -> master) HEAD@{1}: pull --rebase: A local commit
b795f99 (origin/master, origin/HEAD) HEAD@{2}: pull --rebase: checkout b795f9924503c05da91b08e0e9ad3ffb48229bc8
d3379e5 HEAD@{3}: commit: A local commit回答 1
Stack Overflow用户
回答已采纳
发布于 2018-03-15 07:36:15
另一种选择是使用分支重放。在重基过程中，HEAD重放将获得多个条目，但分支重发应该只在最后得到一个条目。(至少在我的测试中起作用。)所以这并不完全是“一个总是相同的命令”，但是
git diff master@{1}..master更接近你想要的。
另一种选择是使用基于时间的重放符号。例如，如果您知道HEAD在过去没有移动，比如5分钟，那么在重基之后立即可以这样说
git diff HEAD@{5.minutes.ago}..HEAD而且，只要在HEAD第一次更新后5分钟内没有奇怪的慢下来，这应该是可以的。但当然，如果rebase导致冲突解决，可能会出现如此缓慢的解决方案，而且总的来说，这是一个半生不熟的解决方案，我只提到这是因为它通常在命令之间的变化较小的情况下工作。
您可以在合并之前记录系统时间，然后说
git diff HEAD@{10:25:03}以避免依赖于重基定时。但是现在又回到记录要插入命令的值了。
更新-删除了我最初提到的一个选项，因为它并没有真正做正确的事情；今天感冒时，头脑有点模糊。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/49301956
复制相关文章
点击加载更多
相似问题
为什么要在合并之前拉？
查询头部分支仍然存在的合并拉取请求
使用revert to state之前的最后一次git拉取--rebase状态
合并拉请求一次合并多个分支
如何在合并之前测试拉请求？
添加站长 进交流群
领取专属 10元无门槛券
AI混元助手 在线答疑
关注 腾讯云开发者公众号
洞察 腾讯核心技术
剖析业界实践案例
腾讯云开发者
