當我將分支變基到 master 中的最新提交時，我應該選擇哪個提交來解決合並沖突？

Question

我正在使用 Beyond compare 來解決合並沖突和 git 擴展來執行 git 命令。 我的情況是這樣的。 使用的注釋是 M 表示主提交，P 表示父分支提交，C 表示子分支提交。

M1 -- M2 -- M3 -- M4 -- ......... -- M50 ...... M60
       \                            /          /
        \                          /          /
         P1 -- P2 -- P3 -- P4 -- P5          /
                \                           /
                 \                         /
                  C1 -- C2 -- C3 -- C4 -- C5

父分支 P5 已合並到 master，父分支中的所有提交都被壓縮，除了一個提交，合並后父分支也被刪除。 我相信這並沒有影響到子分支。 我在子分支的開發已經完成，我想在 master(M60) 上使用當前提交來重新設置子分支。 存在合並沖突，因為分支 P 中的提交和分支 C 中的提交是在相同的文件（DaVinci、C、C#、xml）上開發的。

在 M60 之上重新建立 C 分支，我相信我正在做這樣的事情。

M1 -- ... -- M50 -- ..... M60
                             \
                              \
                               C1 -- C2 -- C3 -- C4 -- C5

我的場景的問題是解決合並沖突。 C、xml 和 C# 文件不是問題，但每次我在 DaVinci 中保存工作區時，DaVinci 都會更新許多鍵（多個位置的某些唯一值），因此此類更改存在於 C 分支的多次提交中。 我正在使用 Beyond compare 來解決合並沖突，與在 M60 上創建新分支並在 DaVinci 中重做工作相比，我似乎花了更多時間來解決合並沖突（因為我知道現在需要做什么）。

是否可以僅在分支中文件的最終版本上解決合並沖突，而不是通過提交解決沖突提交？ （PS 我不需要提交歷史）

如果您有更好的主意，請提出建議。

Answer 1

看看git rebase --onto （ git help rebase ）：

像這樣的事情可能對你有用：

git rebase --onto M60 P2

假設您目前在C5提交上。

這實際上將當時在M60上應用C1 C5的提交，並讓您在此過程中解決任何沖突。

完成此操作后，您可以通過快進或不快進將新的C5合並到 master 中。

Answer 2

是否可以僅在分支中文件的最終版本上解決合並沖突，而不是通過提交解決沖突提交？

無，但有一個快捷方式。 事實上，有多種可能的捷徑； 使用哪一種取決於您真正需要什么。

讓我復制您的原始圖表（ git rebase --onto改動），並假設您使用git rebase --onto正確執行了您想要的操作：

 M1 -- M2 -- M3 -- M4 -- ......... -- M50 ...... M60 <-- master \\ / \\ / P1 -- P2 -- P3 -- P4 -- P5 \\ \\ C1 -- C2 -- C3 -- C4 -- C5 <-- branch

[是成為]

 M1 -- ... -- M50 -- ..... M60 <-- master \\ \\ C1 -- C2 -- C3 -- C4 -- C5 <-- branch

（這里真正的變化是要注意，在提交M60 ，提交C5尚未合並到master中——如果是，我們需要刪除提交M60 ！）。

現在，此圖中的實際錯誤是C1到C5從字面上無法更改。 因此，它們將在存儲庫中保留一段時間，但將不再使用。 新的提交將有一些新的和不同的哈希 ID：

M1 -- ... -- M50 -- ..... M60   <-- master
                             \
                              \
                               C1'--C2'--C3'--C4'--C5'  <-- branch

您在運行git rebase --onto master P2或類似命令時的工作是生成這些新提交中的每一個。

Git 中的每個提交都包含：

• 每個文件的完整快照，加上
• 元數據。

該完整快照是您選擇的任何內容。 這包括這些自動生成的密鑰：

... C、xml 和 C# 文件不是問題，但每次我在 DaVinci 中保存工作區時，DaVinci 都會更新許多鍵（多個位置的某些唯一值），...

如果這些生成的密鑰都需要-如果他們必須在提交，則必須生成它們。

如果您只能在每個中間提交中使用最終密鑰，那是一個快捷方式：生成一次密鑰，然后使用某種自動設備將它們復制粘貼到位。 由您來想出合適的自動裝置； 一旦你這樣做了，你就有了一個快捷方式：生成最終的密鑰並使用這個設備（可能是一個簡單的程序，例如一個 sed 腳本）。

如果您可以提交刪除密鑰的文件，那是一個更好的解決方案。 永遠不要讓這些自動生成的密鑰進入任何文件的 Git 化副本，這樣它們就不會在變基、合並或任何其他 Git 操作期間發生沖突。

不過，據推測，這些鍵有一些用途，當您真正開始構建時，您需要它們。 這就是 Git 的清潔和污跡過濾器的用途。

這些過濾器是您在工作樹和 Git 之間強加的東西。 您必須編寫它們，但也許您現有的密鑰生成軟件已經適用，因此您的“塗抹”過濾器將由“調用密鑰生成軟件”組成。

清潔過濾器的任務是刪除自動生成的垃圾。 它只需要用空（如果可能）或合適但恆定的占位符（如果合適）替換任何自動生成的文本。 這樣Git只能看到占位符，甚至什么也看不到。

污跡過濾器的任務是取出一個清理過的文件——一個剪掉的碎屑，可能有占位符——並放入必要的碎屑，也許是通過替換占位符。

由於各種文件提取命令—— git checkout 、 git switch 、 git reset --hard 、 git restore等——會自動運行你的污跡過濾器，這將在你處理/使用文件時將這些文件放入文件中。 由於git add會自動運行你的清理過濾器，這將從 Git 看到的文件中刪除 cruft。 因此，Git 永遠不會看到任何自動生成的文本，這意味着它永遠不會干擾使用 Git。

這並不適用於每個系統，但可能適用於您的系統。 要了解如何編寫干凈和塗抹過濾器，請閱讀gitattributes 文檔。