Git合併後缺少代碼

我們的GitHub存儲庫存在問題。我將解釋我們的工作流程：Git合併後缺少代碼

開發人員從主線分支創建功能/錯誤修復分支。他們請求他們的更改以重新合併。他們可能會從主線分支重新綁定，以便在工作時獲取最新更新。重新綁定後，他們推動他們的功能分支。

最近使用GitHub Web界面自動合併了兩個拉取請求。隨後 - 合併請求後大約兩天 - 發現這些提交中的更改不在代碼中。歷史上沒有任何跡象表明這些變化已被回覆或被覆蓋。合併本身不會出現在提交歷史記錄中，並且個別提交本身也不會出現。但拉請求已成功合併。其中一個缺失的提交不再提供給櫻桃選擇。當我們嘗試時，我們會得到一個致命的壞對象信息。

我們懷疑發生了一些歷史重寫。我們如何才能找到並且如何防止這種情況發生。我們的工作流程是否存在根本性錯誤？

來源

2012-11-17 Daniel Jones

您是否檢查過發生此事的時間？那裏可能會有一些線索，說明發生了什麼。一般來說，推力被認爲是一個壞主意。如果它們在合併之後強制推送到特性分支，我不確定會發生什麼，但我認爲它不應該在主分支上丟失提交。如果某人意外地被強行推到主線上 - 看不到任何其他可能發生的明顯方式。 – MattJenko

由於類似的問題，我最近因爲類似的問題（其中一位開發人員強迫推送而不詢問任何人）詢問Github是否有可能拒絕Github回購中的強制推送，他們表示現在不可配置，但如果我們輸了有些承諾，我們可以聯繫GH尋求幫助來恢復他們。通常，所有孤立的提交都應該放在GH的reflog以及開發人員的本地回購庫中，直到垃圾收集自動或手動完成。 –

在這裏看到類似的事情：http://stackoverflow.com/questions/5094524/github-prevent-colaborator-from-push-f 似乎GitHub不是很熱衷於實現它。爲了將來，你可以：1）有中間回購，接收東西，設置不同的鉤子，當所有罰款時都會推送給Github，2）限制允許推到中央回購的人數（可能只有1人，每個迴轉一週等）。我知道這個答案可能不令人滿意。 –

您面臨的問題與您的開發商從主分公司重新分派然後強行推動他們的分支機構。 git rebase實際上做的是不支持你所做的所有更改，合併主分支，然後重新應用你的提交（就好像它們是補丁文件一樣）。這將創建一個完全新的哈希完全新的git提交。

總之，舊的提交失敗了，並創建了一個新的相同的提交。

這就是爲什麼它是極其不鼓勵任何公開的工作，因爲你正在有效地改變歷史。如果他們的工作是基於不再可用的變化，那麼任何從你的工作中分支出來的人都將度過一個非常糟糕的日子。

編輯：提交不會丟失本身，它仍然存在於您的回購。但是，它已不再可用在手邊

來源

2013-12-23 15:40:26 Faisal

那麼，沒有。它並不是「不承諾」的，這並不是爲什麼推動重組分支機構不鼓勵。 – jthill

@jthill：謹慎地闡述更多？你只是否定了我所說的話，並沒有解釋爲什麼我說的是錯誤的。另外，http://git-scm.com/book/ch3-6.html，rebasing部分的風險以與我一樣的方式解釋它。也許我錯過了什麼？ – Faisal

他們的解釋與你的不一樣。您使用的「uncommit」這個詞從來沒有出現在那裏，而您的回答比那裏已經有點誇大其辭的說明有更強烈的含義。所有較舊的提交在rebase之後仍然在您的回購中，他們*不*丟失。 – jthill

Git合併後缺少代碼

回答

相關問題