當我是唯一一個在兩個相關分支上工作時，我應該使用git rebase而不是git merge

Question

假設rebase涉及兩個分支A和B 我是唯一一個對這些分支機構進行更改的人，但還有其他人只是為了查看正在發生的事情（審查）而取消了這些分支機構。 他們根本沒有對這些分支進行任何修改。 考慮到rebase vs merge的優缺點，變基顯然是更好的選擇

現在，關於rebase的git文檔提到了關於變基的黃金法則

git rebase的黃金法則是永遠不要在公共分支上使用它。

並解釋為什么它可能是危險的。

我理解rebase和merge之間的區別以及當其他開發人員提交到父分支時情況會出現問題。

即使我是那兩個關於變基的分支機構的唯一開發人員，我是否應該避免這種情況？ 在重新定位之后強行推動並且其他團隊成員試圖拉動那些分支（再次只是為了查看它們，他們沒有做出任何改變）之后會出現什么問題？

Answer 1

要確定是使用rebase還是合並，首先需要了解它們的工作原理。

在git中， 提交是鏈表的鏈，后面的提交引用了先前的提交。

C1<-C2<-C3<-C4

當兩個分支合並時， 創建一個新的合並提交 （由下面的M1表示）

C1<-C2<-C3
 \        \
  \       M1
   \      /
   C4<-C5

其中包含正在合並的提交的引用。 歷史不再是一個鏈表 。 它已成為有向無環圖。

Rebase以不同的方式工作

C1<-C2<-C3 branch1
  \  
       C4<-C5 branch2

#On branch2
git rebase branch1

  C1<-C2<-C3<-C4'<-C5'

Rebase 創建了兩個新的提交C4'和C5'而不是C4和C5，並將分支指針移動到C5'。 這里的歷史記錄是干凈的鏈表 （因為你的分支提交被重新創建並應用到完成了rebase的分支），但是創建了兩個新的提交，意味着為branch2更改了歷史 （之前是C1 <-C4 <-C5）。 因此，每次進行變形時都必須強制推動。

現在回答你的問題：

1. 即使我是那兩個關於變基的分支機構的唯一開發人員，我是否應該避免這種情況？ 在最佳實踐中，最好使用父分支重新定義您的功能分支，然后將您的功能分支合並到父分支 ，因為功能分支是您自己的分支，但父分支也會有其他開發人員提交，如果您重新設置，這可能會丟失你的父分支與功能分支沒有從遠程拉。

2. 在重新定位之后強行推動並且其他團隊成員試圖拉動那些不同的東西后，可能會出現什么問題？ 隨着強制推動它會變得非常糟糕， 將您在本地系統上的任何歷史記錄推送到遠程 。 如果你不使用強制推送，那么你的推送將被拒絕，因為歷史不匹配並提交轉換，你將被要求采取拉動。 此外，如果您在父分支上強制推送其他開發人員提交並且未在本地計算機上提取，則該提交將丟失。

如果其他開發人員試圖從遠程進行拉取，他將會遇到樹沖突，因為他的本地歷史記錄不會遠程使用。

Answer 2

當審閱者提取您的代碼時，可能會出現問題。

Git將獲取重新提交的提交並嘗試將其與審閱者的分支合並。

這將創建一個合並提交 - 如果一切順利或將導致合並沖突。

因為git無法知道新提交是重新設置還是完全不同，所以它將保留舊的pre-rebase提交並將其與post-rebase提交合並。 在任何一種情況下，即使代碼相同，其機器上的提交歷史也將始終與您的不同。

Answer 3

關於變基的“黃金法則”有一個擴展版本：

git rebase的黃金法則是永遠不要在公共分支上使用它。

擴展版本如下所示： 僅對分支名稱使用rebase或其他強制推送類型的運動，其中該名稱的所有用戶都期望產生的行為 。 這是因為每個這樣的用戶可能必須采取一些動作來從這種操作中恢復（“上游變基”）：即，他或她可能必須“拯救”他或她的提交。 如果所有用戶都准備這樣做，並且知道尋找這樣的情況，他們就不會對這個問題感到驚訝。

換句話說，如果你有一個團隊，比如五個程序員，並且你們五個人都同意“pu”（“建議的更新”或“拾取”分支）一直被重新定位，那么改變pu是沒關系的。科。 如果你們中的一個是與基礎重建“發展”，但四個是也不行，它不是確定以變基的“開發”分支。

由於您是唯一使用A和B的用戶和開發人員，因此由您自行決定是否同意自己是否可以重新定義A和/或B.

Answer 4

在重新定位之后強行推動並且其他團隊成員試圖拉動那些分支（再次只是為了查看它們，他們沒有做出任何改變）之后會出現什么問題？

沒有什么能真正“出錯”。 可能發生的最糟糕的事情是“觀察者”在合並時會遇到不必要的麻煩，因為你們新推出的強制提交可能看起來完全不同，現在拉動（即獲取和合並）它們會導致合並沖突 。

即使我是那兩個關於變基的分支機構的唯一開發人員，我是否應該避免這種情況？

雖然變調允許你有一個整潔和線性的git歷史並且肯定有它的好處，但這里有一些想法為什么“合並”有時可能優於“變基”，即使你在“寫”控制你的分支：

1）避免在合並沖突期間由錯誤決策導致的不可逆代碼刪除。

示例：假設您已經在功能分支A工作了兩周，現在您停止工作，而是繼續在分支B工作兩周。 現在經過一段時間后，您覺得是時候再次在分支A上工作了，由於某種原因，您需要將B包含的更改合並到A因此您決定將分支A重新綁定到B 。 在這個變革的過程中出現了幾個合並沖突。 由於判斷力差或僅僅出現意外，您可以刪除A中的部分代碼以解決有利於傳入更改的沖突。 現在，您繼續並完成您的rebase並強制將您的代碼推送到遙控器的origin/A 突然間，您意識到您刪除了分支A中代碼的部分重要且不應刪除的代碼。 但是，由於rebase重寫歷史記錄，與合並不同，您不能簡單地還原rebase並且代碼丟失。

如果你告訴你的團隊中的小輩總是喜歡重組而不是通過在合並沖突過程中做出錯誤的決定來刪除他們的代碼，特別是在將他們的分支重新定位到master上時，上述情況尤其成問題。

當然，除了使用git merge之外，解決這個問題的方法是在執行rebase之前建立備份分支。

2）避免在交互式變基時解決太多沖突。

當您的功能分支包含多個提交時，即您將代碼移動了很多甚至可能來回，然后重新定位可能需要比合並更長的時間，因為rebase將按順序 （！） 順序通過您的分支提交並在每次發現的沖突中停止。 通過合並，您只需將功能分支的當前狀態（即HEAD與您要重新綁定到的分支的HEAD （例如master ）進行比較，並且可能在執行合並時根本沒有沖突雖然在做一個rebase時可能會有一些沖突。 所以在這個意義上，合並可能會為您節省一些時間。