Git合並可以清除更改，如何處理

Question

在合並提交創建期間。 如果沒有進行任何更改並將其保留在合並提交之外。（這種情況確實會發生，並且在某人不太了解他在做什么的情況下會發生很多事情，只需盲目鍵入這些神秘命令即可。或者是由於在GUI git工具上單擊不當。 [他們是非技術人員，我們試圖教他們，但失敗了。我們讓他們使用git，以便他們可以輕松地更新文件並保持最新。]）然后，更改就消失了。 合並提交將沒有this change is undoed msg。 它只是沒有出現在合並提交中。 進行更改的提交具有有關更改的信息。 但是合並后，更改實際上被撤消，沒有任何痕跡。

這太可怕了，我們不能依靠合並提交信息來告知已更改/撤消的內容。 實際上，沒有簡單的方法可說。

解決此問題的一種方法是將合並到master的能力限制為值得信賴的維護者。但是，作為快速發展的小型團隊，這會給維護者增加負擔，並使我們放慢速度。

我想知道是否有人強制執行合並提交以包含有關實際上已還原但未記錄的更改的信息？

還是可以完全禁止合並操作，僅允許重新設置以確保所有更改都被明確記錄？

Answer 1

傻瓜太聰明了， 沒有任何自動化的源工具可以完全做到萬無一失。 :-)

我認為大多數人確實應該比合並更經常地調整基礎（即，我認為git pull的默認操作（在運行git fetch之后運行git fetch git merge是錯誤的））。 但是，這並不是解決“人員合並錯誤”問題的解決方案，因為基礎調整正在合並！ 具體來說，要使提交“變基”，您可以復制提交，就像使用git cherry-pick 。 通常，這是小型且簡單的操作，不需要任何花哨的合並工作，但有時會出錯，並且最終會出現完整的合並。 因此，如果人們要錯誤地合並，他們也可能會錯誤地更改自己的基准-當您對多個提交進行基准重新設置時， 每個提交都會被復制，因此每個提交都是潛在的合並。

這意味着解決此問題的唯一方法是學習如何合並 。 我將不得不把這種指示留給其他人，但是我會注意到，相對於合並之前分支的尖端的提交，您可以看到合並帶來的變化。

假設您有兩個分支，例如，以下一系列提交：

...--o--*--A-----B---C   <-- master
         \
          D--E--F--G--H   <-- feature/X

當您使用git merge feature/X在master上創建一個新的合並提交M時，您將獲得一個有兩個父級的新提交：

...--o--*--A-----B---C--M   <-- master
         \             /
          D--E--F--G--H   <-- feature/X

就像任何提交一樣，此新提交具有自己的獨立源代碼樹。

在您的問題中，您說：

這太可怕了，我們不能依靠合並提交信息來告知已更改/撤消的內容。 實際上，沒有簡單的方法可說。

但是有！ 提交M （無論其實際的哈希ID是什么）都有兩個父級。 這兩個父母之一是“之前在分支上的東西”，即，提交C 如果您想查看從提交C到提交M更改，只需讓Git告訴您 ：

git diff <hash-id-of-C> <hash-id-of-M>

該git diff的輸出與任何 git diff的輸出相同：這是一組指令，向您展示如何獲取提交為C ，以及如何對其進行修改以使其提交為M

如果需要，您還可以讓Git為您提供一組指令，以向您展示如何采用提交為H ，以及如何對其進行修改以使提交為M ：

git diff <hash-id-of-H> <hash-id-of-M>

與任何git diff ，輸出是一組指令：“如何獲取第一次提交中的內容並進行更改以使其成為第二次提交中的內容。”

有一個簡單的方法可以看到這兩個

的確， git log -p通常會顯示“父提交”與“子提交”之間的差異（例如， A與B或B與C差異）在應用於合並提交時不顯示任何內容。 然而：

git show -m <hash-id-of-M>

運行兩個 git diff命令，每個父命令一個，並向您顯示兩個命令 。 將-m視為“顯示合並”或什至“拆分合並（分為兩個差異）”。 這-m標志是可用的git log ，以及：

git log -m -p

將每個提交一次顯示為一個簡單的差異（如果不是合並）或一對簡單的差異（如果是一個合並，有兩個父母）。

（當然，也有幾種方法只能獲得這兩種方法之一 ，但是這個答案已經足夠長了。）