如何在分支中合並修訂的提交而不會發生沖突？

Question

我的工作項目使用Gerrit進行每次審查，並使用修訂的提交模型，在該模型中，您不斷進行修改並推送一次提交，直到獲得團隊批准為止，然后將其拉入遠程主服務器。 這很有效，直到我推送變更列表並且在等待審閱者的同時，我分支並開始從事其他工作。 不可避免地，審閱者會要求進行某些更改，並且原始提交會被修改。 當我想將其合並到分支中時，會發生合並沖突。

這是一個例子：

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

一旦我修改了提交946992，它就會得到另一個哈希值。 我相信git會執行以下操作：

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

無論如何，我都嘗試過在分支機構重新部署master或選擇修改后的提交。 任一種都會引起合並沖突的頭痛，每次我重新設定基准時都必須解決，因此要進行多次修改會使事情變得非常困難。

我有一個解決方法，在這里我重置分支〜1並存儲更改，然后在修改后的提交之前重置另一個〜1提交以獲取，然后重新設置master並重播我的存儲，但是我覺得有更好的方法。 有什么辦法嗎？

Answer 1

每次您“修改”提交時，您實際上都會得到一個新的提交，就像您相信的那樣：git將從索引中git add任何內容（ 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中列出的任何方法而不是HEAD^拼寫起點的SHA-1。 例如， origin/master或origin/branch可能是合適的起點。