假設我是倉庫的維護者，并且想從貢獻者那里獲取更改，那么可能有一些工作流程：我cherry-pick每個人都從遠程提交（按順序）。在這種情況下，git將提交記錄為與遠程分支無關。我merge分支，拉動所有的變化，并增加新的“沖突”提交（如果需要）。我merge每個都從遠程分支分別提交（再次按順序提交），從而允許為每個提交記錄沖突，而不是將所有沖突歸為一個組。為了完整起見，您可以做一個rebase（與cherry-pick選項相同？），但是我的理解是，這可能會使貢獻者感到困惑。也許消除了選項1。在情況2和情況3中，git記錄提交的分支歷史，這與1不同。使用cherry-pick或merge描述的方法之間的優缺點是什么？我的理解是方法2是規范，但是我覺得用單個“沖突”合并來解決大型提交并不是最干凈的解決方案。
3 回答
慕桂英3389331
TA貢獻2036條經驗 獲得超8個贊
這兩個rebase（及cherry-pick），并merge有自己的優點和缺點。我在merge這里主張，但這兩個都值得理解。（在這里找到一個替代的，爭論激烈的答案，列舉了rebase首選的情況。）
merge優于cherry-pick和rebase一對夫婦的原因。
堅固性。的的SHA1標識提交識別它不僅在其本身，而且相對于它前面的所有其他的提交。這樣可以保證給定SHA1上所有克隆的存儲庫狀態都相同。從理論上講，幾乎沒有人進行過相同的更改，但實際上是在破壞或劫持您的存儲庫。您可以選擇單個更改，并且它們可能是相同的，但您不能保證。（作為次要的次要問題，如果其他人再次在同一提交中進行新的挑選，則新的挑選出的承諾將占用額外的空間，因為即使您的工作副本最終相同，它們也會出現在歷史記錄中。）
易于使用。人們傾向于
merge相當容易地理解工作流程。rebase往往被認為更高級。最好兩者都理解，但是不想成為版本控制專家的人（根據我的經驗，其中包括許多非常擅長于他們的工作，但又不想花費額外時間的同事），他們會更輕松時間只是合并。
即使是繁重的工作流程rebase，cherry-pick在某些情況下仍然有用：
不利的一面
merge是歷史混亂。rebase可以防止一連串的提交分散在您的歷史記錄中，就像您定期合并其他人的更改一樣。實際上，這就是我使用它的主要目的。您要非常小心，永遠不要rebase編碼與其他存儲庫共享的代碼。一旦完成了提交，push其他人可能已經在其上提交了，重新定基最多將導致上面討論的那種重復。在最壞的情況下，您可能會得到一個非?；靵y的存儲庫和細微的錯誤，這將使您花費很長的時間來尋找信息。cherry-pick有助于從您基本上決定放棄的主題分支中抽取一小部分更改，但是意識到其中有一些有用的內容。
至于更喜歡將許多更改合并為一個：這只是簡單得多。一旦您擁有大量變更集，那么合并各個變更集可能會變得非常乏味。git（以及Mercurial和Bazaar）中的合并分辨率非常好。大多數時候，即使合并很長的分支，也不會遇到重大問題。通常，我會一次合并所有內容，并且只有在遇到大量沖突時，我才備份并重新運行合并程序。即使那樣，我也會大塊地做。作為一個非常真實的例子，我有一位同事，他有3個月的更改要合并，并且在250000行代碼庫中遇到了9000個沖突。我們要解決的問題是一次合并一個月的價值：沖突不是線性累積的，而逐步進行合并會產生很大的結果少于9000個沖突。這仍然是一項艱巨的工作，但不如一次完成一次提交那么多。
慕森王
TA貢獻1777條經驗 獲得超3個贊
我認為應該在需要的情況下保留櫻桃采摘，例如，如果您直接在“主”分支（樹干，主開發分支）上進行了一些修復，然后意識到也應將其應用于“維護” '。您應該基于合并或重新設置工作流（或“ git pull --rebase”）。
請記住，從Git（具有不同的SHA-1標識符）的角度來看，精心挑選或基于基礎的提交不同于原始提交，因此它不同于遠程存儲庫中的提交。（Rebase通常可以處理此問題，因為它檢查補丁程序ID，即更改，而不是提交ID）。
同樣在git中，您可以一次合并許多分支：所謂的octopus merge。請注意，章魚合并必須成功而沒有沖突。但是，它可能有用。
HTH。
慕標5832272
TA貢獻1966條經驗 獲得超4個贊
Rebase和Cherry-pick是保持干凈提交歷史記錄的唯一方法。避免使用合并，并避免產生合并沖突。如果使用的是gerrit，則如有必要，將一個項目設置為Merge，將一個項目設置為Cherry-pick模式，然后嘗試一下。
- 3 回答
- 0 關注
- 1155 瀏覽
添加回答
舉報
0/150
提交
取消