Git：這種分歧是如何發生的？

Question

情況

• 我有一個本地Git倉庫。

• 我只有分支： master 。

• 我曾經有另一個分支，但是我將其合並到master ，然后將其刪除。

• 這種合並和刪除的分支從fe6263e分叉。

• 0c81926是c79dc19的- c79dc19

• 沒有標簽，也沒有其他指向c79dc19 。 我知道，如果某個對象指向一個修訂的提交，則該提交將繼續顯示在歷史記錄中。 但這種情況並非如此。

問題

• 為什么歷史線沒有變平？

• 為什么仍顯示c79dc19 ？

• 這是怎么發生的？

正如我提到的，沒有任何指向它的東西，我做了一個git -gc來清理所有掛起的提交。

Answer 1

沒有標簽，也沒有其他指向c79dc19 [提交]

那不是歷史所顯示的。

嘗試運行git show HEAD它會顯示合並的兩個父對象。 從您的圖表中看起來像是c79dc19 ，這就是為什么它出現在您的歷史記錄中。

最有可能的是，該分支實際上是從c79dc19開始的（因此該分支已經在主服務器上），或者當c79dc19是其分支機構時，該分支作為快速轉發合並到了master。

---

工作圖：

1. 初始狀態

    fe62 <=master <=HEAD 

2. 新提交

    fe62 <- c79d <=master <=HEAD 

3. 結帳新分支

    fe62 <- c79d <=master <=branch <=HEAD 

4. 修改（在分支上）給出一個新的提交0c81 ，它將替換該分支上的c79d ，但不會更改master c79d

    fe62 <- c79d <=master \\- 0c81 <=branch <=HEAD 

Answer 2

您從c79 master創建了新分支，所以master繼續指向該分支。 然后，您從新分支進行了修訂，因此主分支和新分支的歷史有所不同。

需要注意的一件事是，修訂實際上並沒有修改提交。 提交是一成不變的。 一項修訂基於另一個修訂創建一個新的提交。

如果要展平它，則將master指向上一個提交並合並到尖端。

git checkout -b temp
git branch -f master fe6263e
git checkout master
git merge f6429eb

Answer 3

很難百分百確定，但這經常發生，因此這可能是正確的答案。

您提到只有一個分支，稱為master 。 我相信你！ 但是您沒有一個存儲庫，或者更確切地說，有您的克隆，然后還有其他一些克隆，可能在遠程上，您將其稱為某些中央服務器（例如GitHub或公司服務器）上的origin 。 您將提交發送到服務器，並從服務器獲取提交。

您還提到了使用git commit --amend 。 請參閱git commit --amend如何工作？ （如Jubobs的評論所述 ）以獲取詳細信息，但是總之，這不會更改提交，只是將其推到一邊，以支持新的替換提交。 不過，大概是您已經推送了原始提交，因此現在它位於另一個存儲庫的master分支中。

因此，您現在擁有0c81926作為master的技巧，而他們（來源）具有c79dc19 。 然后，您進行了新的提交f6429eb ，以便您的master指出這一點。

然后，我敢打賭，您運行了git pull （很可能尚未配置或指示git pull進行git rebase ）。 先運行git fetch然后進行git merge 。 git fetch與您的remote， origin進行了檢查，發現它的 master指向提交c79dc19 。 git pull運行的git merge將其分支與您的分支合並，產生合並提交706b1ef 。

最后，這意味着您確實有兩個不同的分支：master和master。 只是其中之一是您的主人，而其中之一是其他人的主人。

請注意，您可以擺脫c79dc19提交和合並，例如，使用git rebase -i fe6263e （混亂開始之前的那一點）：刪除不需要的額外提交，然后讓git rebase展平剩余的歷史記錄並忽略合並。 （或者，使用Jeff Puckett II的答案中的方法 。）但是，一旦執行此操作，您的歷史記錄就會與origin歷史記錄有所不同 ：他們有一個提交（您嘗試擺脫的那個c79dc19 ）沒錯 因此，您將無法不強制執行就進行推送（可選地，“強制租賃”，希望其master為c79dc19 ，以確保自上次檢查以來他們沒有得到更多提交）。