从master更新Git分支

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

我是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楼

你基本上有两个选择：

你合并。这实际上非常简单，并且是一个完美的本地操作：
```
git checkout b1 git merge master # repeat for b2 and b3
```
这样就完全保留了历史记录：您从master中分叉，对所有分支进行了更改，最后将master中的更改合并到了所有三个分支中。
git可以很好地处理这种情况，它设计用于同时在各个方向发生的合并。您可以相信它能够正确地将所有线程组合在一起。它根本不关心分支b1是否合并master ，或者master合并b1 ，合并提交看起来与git完全相同。唯一的区别是，哪个分支最终指向此合并提交。
你的变形。具有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在分支机构之间应用单个提交。

来源：oschina

链接：https://my.oschina.net/u/3797416/blog/3152392

标签

master

git

git提交代码