替代git rebase

Question

我是git的新手。 比方說，我從遠程本地分發了一個存儲庫，它被稱爲localRepo。有兩個分支Master和testBranch。 testBranch提前100次提交併提交5000次提交。對testBranch進行了更改，但從未合併到Master中。所以我想把testBranch放到我分叉的localRepo的master上。

我做了以下內容：

1. git checkout testBranch
2. git fetch origin
3. git rebase origin/Master

我遇到一些矛盾，我用手使用合併工具（kdiff3）解決它，並說刪除或修改文件使用等...

由於它落後5000次左右，是否有可能發生更多衝突？如果我像這樣手動解決衝突，我想知道需要多少天！這將是非常乏味和不切實際的。

我是以正確的方式去做的嗎？

這是這種情況的唯一方法嗎？或者其他有效的方式？

Answer 1

不，不可以替代rebase。就是這樣。獲得的經驗：早日兌現，經常兌現。落後於提交意味着你遲早會浪費很多時間。兩年前，我編寫併合並了一個200個提交功能的分支，這個分支是在六個月的時間內開發的。我不知道在這六個月內合併了多少次提交。但我相信他們也有數千人。如果我等到我完成我的特色分支，並試圖重新綁定，我會遇到很大的麻煩。但我每天都會重新扮演一個角色，最終的合併變成了一個大而胖的漢堡包。

如果您的功能分支中的一百次左右的提交可以在邏輯上被劃分成小塊，那麼可能會將rebase分成幾個階段。如果你的功能分支的一百個提交中有幾個主要的檢查點，並且在每一點你的功能分支都是全功能和可測試的，那麼你可以考慮只提交所有提交到檢查點的提交，然後對這些提交進行重新綁定，然後測試它們。然後，一旦你測試了你的提交的最初塊在rebase之後工作，繼續並重新提交commit，直到下一個檢查點。

當你立即重新綁定所有東西時，git只會在每次失敗重置提交時停止。至少這樣你可以更好地控制這個過程。您可以在預定的檢查點停止並暫停，然後對重新發布的更改進行廣泛的迴歸測試，然後繼續。

但是，請注意，爲了實現這個功能，您必須完美地跟蹤您的功能分支上的所有提交;哪一個已經重新設計，哪些沒有。

Answer 2

您可以改爲使用merge。

的merge的優點：一是必須解決積累唯一的testBranch當前最後狀態和master（儘管衝突的地方可以在行號的方面是相同的）當前狀態之間不兼容的變化，而不是在master的新提示中重新應用testBranch的每個提交（這是rebase的工作方式）。 merge的缺點：歷史圖變得更加複雜，有些人不喜歡這樣複雜的圖，特別是那些從「傳統」VCS遷移到簡單樹狀歷史圖的人。

有時tools like git rerere可能幫助，尤其是當處理一組重複性衝突時。但肯定不是銀彈。

是的，按照@SamVarshavchik的建議：最好定期跟蹤上游變化，並在功能分支中「與他們保持一致」，而不是在一個晴朗的早晨出現數千條線路衝突。或者不是那麼陽光明媚，或者不是一個早晨 - 實際上這並不重要，因爲人們不得不花費數小時，數天甚至數週來解決這個問題。

通常它有助於將您的巨大功能分支分割成更小的部分，並儘快將這些更改推回到上游。因此，你的同事會使用你的代碼和你的方法，而不是發明自己的[衝突]，所以合併/重組對於所有各方來說都會更簡單。

此外，在您的項目中使用強制性的同行代碼審查系統也是很有用的，即使是在功能分支中提交也是如此。如今，我對人類通過簡單地查看複雜代碼中的可能錯誤的能力持懷疑態度。但至少所有參與開發特定代碼的人都知道提議的變更，並可以協調不同分支機構的工作。