從master更新Git分支

我是Git的新手，如今我處於這種狀況：

• 我有四個分支（master，b1，b2和b3）。
• 在我使用b1-b3以後，我意識到我在分支主機上有一些改變，應該在全部其餘分支中。
• 我改變了master所須要的東西......這是個人問題：

如何使用master分支代碼更新全部其餘分支？

---

#1樓

git rebase master是執行此操做的正確方法。 合併意味着將爲合併建立提交，而從新設置則不會。

---

#2樓

若是您一直在分支機構上工做，或者在您從事某些工做時在其餘分支機構中發生了不少事情，那麼最好將您的分支機構從新設置爲主機。 這使歷史保持整潔，使事情更容易遵循。

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

筆記：

• 不要改變你與他人合做的分支機構。
• 你應該在你將要合併的分支上進行從新定義，這可能並不老是掌握。

在http://git-scm.com/book/ch3-6.html上有一章關於變基的內容，以及網上的大量其餘資源。

---

#3樓

你基本上有兩個選擇：

1. 你合併。 這實際上很是簡單，而且是一個完美的本地操做：

   git checkout b1 git merge master # repeat for b2 and b3

   這樣就徹底保留了歷史記錄：您從master中分叉，對全部分支進行了更改，最後將master中的更改合併到了全部三個分支中。

   git能夠很好地處理這種狀況，它設計用於同時在各個方向發生的合併。 您能夠相信它可以正確地將全部線程組合在一塊兒。 它根本不關心分支b1是否合併master ，或者master合併b1 ，合併提交看起來與git徹底相同。 惟一的區別是，哪一個分支最終指向此合併提交。

2. 你的變形。 具備SVN或相似背景的人發現這更直觀。 命令相似於合併狀況：

   git checkout b1 git rebase master # repeat for b2 and b3

   人們喜歡這種方法，由於它在全部分支中保留了線性歷史。 然而，這種線性歷史是謊話，你應該意識到它是。 考慮這個提交圖：

   A --- B --- C --- D <-- master \\ \\-- E --- F --- G <-- b1

   合併致使真實的歷史：

   A --- B --- C --- D <-- master \\ \\ \\-- E --- F --- G +-- H <-- b1

   然而，rebase給你這個歷史：

   A --- B --- C --- D <-- master \\ \\-- E' --- F' --- G' <-- b1

   關鍵是，提交E' ， F'和G'從未真正存在過，而且可能從未通過測試。 他們甚至可能沒法編譯。 經過rebase建立無心義的提交實際上很是容易，特別是當master中的更改對b1的開發很重要時。

   這樣作的結果多是，您沒法區分E ， F和G三個提交中的哪個實際引入了迴歸，從而減小了git bisect的價值。

   我不是說你不該該使用git rebase 。 它有它的用途。 可是每當你使用它時，你須要意識到你在撒謊的事實。 你應該至少編譯測試新的提交。

---

#4樓

您有兩種選擇：

第一個是合併，但這會爲合併建立額外的提交。

結賬每一個分支：

git checkout b1

而後合併：

git merge origin/master

而後推：

git push origin b1

或者，你能夠作一個rebase：

git fetch
git rebase origin/master

---

#5樓

您能夠合併，或者您可使用git cherry-pick在分支機構之間應用單個提交。