Git選擇錯誤的祖先提交

Question

我與其他一些人一起使用git。我們有一箇中央存儲庫，然後是本地跟蹤分支。最近，我們遇到了一個問題，git會錯誤地認爲主分支和新分支的最後一個共同的祖先提交是隻在我們創建新分支後才被推送的提交，導致當我們合併時撤銷的更改例如：

Alice在主分支的本地副本中進行了一些更改並提交它們，但不推送。說她改變了文件foo.txt的第一行。

Bob從主分支的中央副本中拉出。據他所知，他是最新的。

兩者都繼續工作。在某個時候，Alice推動。後來，鮑勃稱git日誌，並認爲他的分支據稱是愛麗絲改變foo.txt的提交的祖先，儘管他從未拉取過她的更改。正如所料，鮑勃合併時，愛麗絲的變化消失了。

我一直無法重現這一點，但可以從日誌中知道它確實發生在一個點上（即我們有一個分支據稱是對源文件進行更改的提交的後繼者，但這些變化並不存在）。這種事情怎麼可能，我怎麼能阻止它？

Answer 1

有人在某個階段強制推送一些更改並覆蓋特定的散列提交（在推送中使用-f）。這聽起來像你的情況下可能會發生這種情況。

如果，可以幫助你，我們的工作流程是拉/推時總是使用衍合：

一個人做了改變，並推動他們。

某乙繼續工作，做當地承諾

在某些階段某乙要實時推送。要做到這一點。

• 人B確保本地分支是乾淨的（如果沒有的話）。

• 某乙運行的git拉--rebase（這將下載所有的變化和重新申請了自己在新的頭頂）

• 如果有任何衝突某乙來解決衝突。

• 人B finaly現場推送本地副本。

並重新應用同樣的過程，與某甲爲原點頭後面的一個需要去拉變基

，推動現場時，切勿使用-f，這是非常糟糕的。

更多信息：當人A做了一個承諾，推動它活着，然後意識到還有一個缺陷時，推動力是誘人的。人A對最後一次提交做出了修改。然後推動這個承諾的唯一方法就是做一個推 - f ...這對那些在他們自己的副本上工作的人來說真的很糟糕，因爲他們已經完成了本地提交他們的副本並推送實況