从master更新Git分支

2018-06-17 09:59:53

我是Git的新手，现在我处于这种情况：

我有四个分支（master，b1，b2和b3）。

在我完成b1-b3之后，我意识到我应该在所有其他分支上对分支主人进行更改。

我改变了我在master所需要的......这是我的问题：

如何使用master分支代码更新所有其他分支机构？

你有两个选择：

第一个是合并，但这会为合并创建额外的提交。

结帐每个分支：

git checkout b1

然后合并：

git merge origin/master

然后推：

git push origin b1

或者，你可以做一个rebase：

git fetch
git rebase origin/master

你基本上有两个选择：

你合并。这实际上很简单，并且是一个完美的本地操作：

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

这就像历史发生一样：您从主人那里分流，您对所有分支进行了更改，最后您将主人所做的更改并入所有三个分支。

git可以很好地处理这种情况，它被设计用于同时发生在各个方向的合并。你可以相信它能够正确地把所有的线程结合在一起。它根本不在乎分支b1合并master ，还是master合并b1 ，合并提交看起来都一样。唯一的区别是，哪个分支最终指向这个合并提交。

你重新分配。拥有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

然而，这种转型给了你这样的历史：

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

关键是，承诺E' ， F'和G'从来没有真正存在过，并且可能从未经过测试。他们甚至可能不会编译。实际上，通过rebase创建无意义的提交非常容易，尤其是当master的变化对b1的开发很重要时。

这样做的后果可能是，你无法区分三个提交E ， F和G哪一个实际引入了回归，从而降低了git bisect的价值。

我不是说你不应该使用git rebase 。它有它的用途。但是，无论何时你使用它，你都需要意识到你对历史的撒谎。你至少应该编译测试新的提交。

git rebase master是正确的方法。合并意味着将为合并创建提交，而重新分配则不会。

链接地址: http://www.djcxy.com/p/49227.html