Git 在合並到功能分支時恢復主恢復提交

Question

我一直在一個單獨的分支big-feature上開發一個主要的、長期的特性。 在其開發過程中，我也一直在對master進行較小的無關更新（從技術上講，我一直在從master對他們自己的分支進行較小的更新，然后將它們合並到master 。）

每次完成對master的一些更改時，我一直習慣於將master合並到big-feature中，這樣功能分支不會偏離master太遠，並且希望在 big feature 完成后合並會更容易。

但是，在最近的一些工作之后，我不小心將big-feature合並到了master中。 我試圖用revert來糾正這個問題，實際上之前的代碼 state 似乎已經恢復了。 但是，我仍然看到master的提交歷史中列出的big-feature提交的完整歷史，以及頂部的merge和revert 。

問題是，當我現在對master進行小改動並嘗試將master合並到big-feature時，所有big-feature的代碼都會恢復為master的代碼。 我只能猜測master的revert被合並到big-feature並刪除了big-feature中的所有提交。

希望這是半連貫的。

問題：

1. 我的診斷正確嗎？
2. 我定期將master合並到big-feature中的策略是一個壞主意嗎？
3. 主要問題：我該如何解決這個問題？

PS我還嘗試在錯誤合並之前將master hard reset為提交，但這並沒有從big-feature中刪除所有提交，這讓我感到驚訝嗎？

Answer 1

我不小心將 big-feature 合並到 master 中。 我試圖用 revert 來糾正這個問題

這不是撤消合並的方法。

恢復是一個全新的提交，它是人為創建的，以便在未來的歷史中添加對之前的某個提交的否定。

撤消合並的方法是在您進行合並時所在的分支上，然后簡單地reset --hard一次提交，即在合並提交之前的提交。 它沒有名稱，因此您必須使用HEAD~1表示法或使用該提交的 SHA。 合並提交被丟棄，並且很快，我們就回到了合並之前的位置。

（你說你試過了，但你沒有給出你給出的實際命令，所以沒有理由認為你給出了正確的命令。）

在這個例子中，我在master上創建了提交 A、B 和 C 並在feature上提交了 Z，我已經將feature合並到master中——你可以看出這是因為（1）我在master上，以及（2）合並提交是master的一部分，而不是feature的一部分：

*   a65559d (HEAD -> master) merge commit
|\  
| * c6c9d90 (feature) Z
* | caa732e C
* | 11bbc44 B
|/  
* 92e934a A

請注意 SHA 編號。 假設我們對這一舉動感到遺憾。 因此，我們的目標是刪除a65559d ，以便將master放回caa732e ，即我們合並feature之前的位置。 我們目前在master上，所以我們要做的就是說：

git reset --hard caa732e

結果：

* c6c9d90 (feature) Z
| * caa732e (HEAD -> master) C
| * 11bbc44 B
|/  
* 92e934a A

正是我們想要的。

Answer 2

注意：僅當您能夠覆蓋歷史記錄時，此答案才適用。 只有在您沒有將更改推送到遠程或者您知道這不會影響其他開發人員的情況下才應該這樣做（例如，沒有或您可以與項目中的每個人交流您將要做什么做）

---

我該如何解決？

我假設當您將big-feature合並到 master 時發生的事情是快進合並。

在這種情況下，使用git reset重置為某些特定提交可能不起作用，因為我們來自master和big-feature的提交可能已經混合。 相反，我們可以使用git reflog來查找 state 在我們進行合並之前所在的master節點，然后將master節點重置為該 state。

git reflog master # Show the history of updates to the tip of master.
                  # Find the line that says "master{n}: merge big-feature: Fast-forward"
                  # and note the reference number n

git switch master # checkout master if necessary
git reset --keep master@{n+1} # Now reset master to the reference just before merge

我定期將大師合並到大功能中的策略是一個壞主意嗎？

如果再次，您可以覆蓋歷史記錄，我建議您定期將您的feature分支重新設置在master上。 這為您提供了一個優勢，即在您的feature分支上擁有干凈的歷史記錄，這使得與分支的交互更容易，包括在這種情況下。

Answer 3

我懷疑這里的問題是，當您現在將master合並到big-feature時，Git 正在拉動該合並還原提交，然后在功能上撤消了您在big-feature中發生的一堆工作。 雖然可能有一種更優雅的方式來處理這個問題，但一個簡單的解決方案是從master中挑選您希望也包含在big-feature中的提交：

# from big-feature
git cherry-pick ABCD

以上假設ABCD是master中提交的 SHA-1 hash，它具有您想要引入big-feature的次要修復。

使用這種方法需要更多的工作，因為您需要准確地確定需要輸入哪些提交，但它避免了不再適合您的合並蠻力方法。