从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在分支机构之间应用单个提交。