Question

我的工作项目使用Gerrit进行每次审核和修改后的提交模型，在这种情况下，您可以继续修改并推送一个提交，直到它获得团队批准，然后将其拉入远程主服务器。这很有效，直到我推送更改列表并等待审阅者，我分支并开始处理其他事情。不可避免地，审稿人会要求进行一些更改，并且原始提交会得到修改。当我想将它合并到分支中时，我会遇到合并冲突。

以下是一个例子：

dd2e86 - 946992 [master]
           \
            76cada [branch]

一旦我修改了提交946992，它就会得到另一个哈希值。我相信git会做这样的事情：

dd2e86 - c2ba32 [amended master]
    \
     946992 - 76cada [branch]

无论如何，我已经尝试在分支上重新设置master或者修改提交的提交。任何一个人都会产生合并冲突的头痛，每次我重新定义时都必须解决这个问题，所以多次修改以掌握使事情变得非常困难。

我有一个解决方法，我重置分支〜1并存储更改，然后重置另一个~1提交以获得修改后的提交，然后rebase master并重播我的stash，但我觉得有更好的方法。有解决方案吗

Answer 1

每当你“修改”一个提交时，你真的只是得到一个新的提交，正如你所相信的那样：git将您放入索引的任何内容（git add ed）并从中进行新的提交，复制先前的HEAD提交消息，但使新提交的父级成为先前的HEAD提交的父级，然后使新提交成为新的HEAD。因此，您对后续提交图的绘制是正确的。

如果您想要处理的“其他内容”与其他修补程序无关，那么处理此问题的简单方法是在您等待批准之前根据提交进行修复：

         946992   <-- proposed-fix-A  # waiting for approval
          /
... - dd2e86      <-- origin/master (or whatever)
          \
         xxxxxx   <-- proposed-fix-B

而不是：

           xxxxxx <-- proposed-fix-B
             /
         946992   <-- proposed-fix-A  # waiting for approval
          /
... - dd2e86      <-- origin/master (or whatever)

这样，xxxxxx的父提交是dd2e86，它不会改变，而不是946992（或可能）。批准并推送proposed-fix-A后，您可以在最终版本上重新proposed-fix-B，无论其SHA-1是什么。

（如果“别的东西”确实需要第一次修复，那么你几乎无法解决冲突。）

获得“建议的修复B”的方法（即，作为其父提交）除了当前分支的提示之外的一些提交是告诉git branch或git checkout -b从哪里开始：

... work work work ...
git commit -m "proposed fix A"
# and submit it for review
# at this point, HEAD is proposed fix A, but
# now you want to create a new branch based
# on its parent commit, i.e., HEAD^, so:
git checkout -b fix-B HEAD^
... work work work ...
git commit -m "proposed fix B"

根据需要重复其他分支。请注意，您可以使用gitrevisions中列出的任何方法拼写起点的SHA-1，而不仅仅是HEAD^。例如，origin/master或origin/branch可能是一个合适的起点。

如何在没有冲突的分支中合并修改后的提交？

1 个答案: