使用git merge單獨提交沖突解決方案

Question

我正在嘗試將一個大主題分支合並到主服務器中，但我想要一個單獨的提交來顯示沖突解決方案是如何發生的。 目標是讓一個提交顯示“這些文件沖突以及它們如何沖突”，下一個提交將顯示“這就是解決沖突的方式”。 即第一次提交將包含沖突標記 。

原因是大主題分支已經過審查和測試，主分支也是如此。 在合並中，我們只想查看需要一些工作的部分（沖突和其他合並工作）。

這是我到目前為止所做的：

git checkout master
git checkout -b merge-from-topic
git merge topic

要記錄有沖突的文件，我使用臨時文件：

git diff --name-only --diff-filter=U >conflicts.txt

首先，我只是將帶有沖突標記的文件添加到提交中：

xargs git add <conflicts.txt
git commit

然后我創建另一個分支（用於審查目的），我想在其中進行沖突解決：

git checkout -b resolve-merge-from-topic

為了恢復沖突，我試過了

xargs git reset HEAD^ -- <conflicts.txt

但是后來git mergetool說沒有文件需要合並，盡管我工作樹中的文件有沖突標記。

如何恢復conflict.txt中列出的文件，以便我可以在它們上使用git mergetool ？

我也對其他獲得“單獨提交沖突解決”效果的方式持開放態度。

Answer 1

git merge將留下沖突標記。

然后（通常）調用git mergetool （使用您喜歡的--tool ）來解決沖突。 大多數情況下，這將導致分階段的變化 。 這是你想要改變的 （例如使用git reset ）。

現在單獨提交'raw'合並，然后git add . && git commit -m 'resolutions' git add . && git commit -m 'resolutions' git commit -am 'resolutions' git add . && git commit -m 'resolutions'或git commit -am 'resolutions'來添加沖突解決方案。

請注意，這會在合並邊界修訂版中留下“破損”構建。

步驟：

git checkout -b be_merged       # start a temp branch for the merge (safety)

git merge --no-commit diverge   # initiate merge from a diverged branch
git status                      # shows conflicts
git mergetool                   # resolve them as always
git status                      # shows resolutions as staged
git reset                       # unstage the changes
git status                      # shows unstaged changes (good!)
git commit -m 'merge, conflicts pending'   # commit the merge
git commit -am 'conflicts resolved'        # commit the resolutions

Answer 2

如果你真的堅持要獲得合並歷史，那么最好的辦法是使用git-imerge

AFAIK git imerge可以讓您選擇是否應保留合並歷史記錄

REF：

1. http://softwareswirl.blogspot.de/2013/05/git-imerge-practical-introduction.html

作者博客的一篇文章：

git merge疼痛

• 你需要解決一個大的沖突，它會在合並的兩邊混合很多小的變化。 （解決大沖突很難！）
• 合並是全有或全無：
  1. 沒有辦法保存部分完成的合並，所以
     • 您無法記錄進度。
     • 您無法暫時切換到另一個分支。
     • 如果您犯了錯誤，則無法僅還原部分合並。
     • 如果你無法解決整個沖突，那么除了重新開始之外沒有什么可做的。
  2. 沒有辦法測試部分完成的合並 - 在沖突完全解決之前，代碼甚至不會構建。
• 與同事合並很難合作。

這可能正是您首先需要沖突提交的原因。

---

另一方面，不同的觀點：

在一個簡單的項目中，合並更改應盡可能保持最小化為什么要說的是，觸及存儲庫中所有文件的合並將使您在將來真正感到痛苦。 好像你要將你的分支與一些主要分支合並，假設你在生產分支上工作，而發布是從發布分支完成的，分支維護者只會嘗試用他的分支重新分支你的分支。

現在，如果你有一個觸及該地方所有文件的提交，這將是一個閱讀不好的東西，因為合並最有可能會發生沖突（主要的一個，可能是你所做的沖突提交）所以維護者會有2個選項：

1. 自己合並
2. 拒絕合並，讓你做臟工作

維護者更有可能選擇后者，因為對他來說這更容易。

因此，您將花費更多時間來解決沖突，而不是做一些富有成效的工作。

注意：

第二個視角僅適用於具有簡單跨度的要素主題。 合並具有更大跨度的特征主題時，最好使用imerge並保留歷史記錄，這樣您將擁有較小的提交，並且rebase不會很痛苦。

Answer 3

這是一個非常糟糕的主意。 您希望始終擁有穩定的代碼庫。 為什么你會在一個沖突的狀態下推送代碼。

如果要查看沖突是如何解決的，請對文件執行diff操作並查看其歷史記錄。