Git - 如何在不重疊的情況下在一個步驟中解決來自每次提交的衝突？

A---B---C topic 
/
D---G master

說我在git中有上述分支結構。如果我做git checkout topic，然後git rebase master，從我所經歷的情況來看，我將不得不一次解決提交A，B和C的衝突。我正在尋找一種避免必須一次解決每次提交衝突的方法。在重新綁定期間壓縮提交看起來像是一種選擇，但可以保持提交是否分離，並且只需要爲最近的「主題」提交執行衝突解決？基本上我想知道是否有可能將「主題」重定位到「主」上，並且只需要解決「C」和「G」之間的衝突而不會將所有提交壓縮爲一個。也許我誤解了一些東西，但在我看來，由於「C」是最近的提交，也是我感興趣的提交，爲什麼我必須先解決「A」和「B」的衝突？我對git pull --rebase也特別感興趣。Git - 如何在不重疊的情況下在一個步驟中解決來自每次提交的衝突？

感謝所有幫助

來源

2013-12-09 Multibran

打開['git rerere']（https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html）。另請參閱http://git-scm.com/blog/2010/03/08/rerere.html – torek

Q1：如何解決所有衝突一次？

答：你不可以，因爲在重組期間，基準工具無法預見即將發生的事情。 Rebase真的是一個腳本化的櫻桃選擇。你可以嘗試首先將啓用了rerere的可支配分支上的變更合併，但是1）它需要更多的步驟，而不僅僅是解決每個衝突，2）沒有保證你不必解決衝突。

Q2：也許我誤解了一些東西，但在我看來，由於「C」是最近的提交和我感興趣的，爲什麼我必須解決「A」的衝突並且「B」先？

答：是的。當您重新綁定時，無論如何您都不會更新主設備，您只會將更改應用於較新的主設備版本。所以，也許你會想要拋棄C或B甚至是A.我認爲革命性的git是你必須停止思考「最新的代碼」，而是根據分階段的變化推出和/或將新的開發/功能部署到生產/部署/交付中）。如果我能夠準確地做到這一點，我會試圖引用布朗爵士給麥克利。

所以是的，這可能意味着最好的解決方案是壓縮所有的提交作爲一個。雖然git rebase背後的一點是，規範不應該是衝突，衝突應該是可預見的。不出所料。因爲衝突是變化和變化應該是新的version的同義詞。如果當你添加新的東西，重構或純粹的錯誤修復時衝突即將出現，它比窮人git功夫/功能更像是一個糟糕的體系結構的症狀。因人而異。

來源

2013-12-10 02:43:36 Sebastien

這非常有幫助，特別是關於「最新代碼」的評論。我問的主要原因是，自從我最後一次從遠程主分支上拉出來以後，有時候它會發生幾次本地提交 - 然後我會執行'git pull --rebase'（這是我被鼓勵去做的）並且有解決過去那些代碼已被覆蓋並且不再需要的提交的衝突，一次一個。我很確定我沒有使用最聰明的工作流程，但我會盡量不做這麼多無聊的本地提交。 – Multibran

解決這個問題有很多技巧。從上游撤回的承諾是不好的做法，但你最不可避免的要面對。我最喜歡解決這些問題的技巧是基本上1）保留原始更改的safec副本2）對上游提交（而不是原始/主文件）逐漸進行rebase。每次成功的部分改版都是勝利。 3）你可以檢查origin/master -b test和git rebase -i master並壓縮上游提交。重新壓扁上游應該很容易。該版本應該更容易在原產地/主版本上重新分配。不確定是否清楚。 – Sebastien

Git - 如何在不重疊的情況下在一個步驟中解決來自每次提交的衝突？

回答

相關問題