从 master 更新 Git 分支

Update Git branches from master

提问by Ionu? Staicu

I'm new to Git, and now I'm in this situation:

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

• I have four branches (master, b1, b2, and b3).
• After I worked on b1-b3, I realized I have something to change on branch master that should be in all other branches.
• I changed what I needed in masterand... here is my problem:

• 我有四个分支（master、b1、b2 和 b3）。
• 在我处理 b1-b3 之后，我意识到我在分支 master 上有一些应该在所有其他分支中改变的东西。
• 我改变了我需要的东西master......这是我的问题：

How do I update all other branches with masterbranch code?

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

采纳答案by Chris Kooken

You have two options:

您有两个选择：

The first is a merge, but this creates an extra commit for the merge.

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

Checkout each branch:

结帐每个分支：

git checkout b1

Then merge:

然后合并：

git merge origin/master

Then push:

然后推：

git push origin b1

Alternatively, you can do a rebase:

或者，你可以做一个rebase：

git fetch
git rebase origin/master

回答by cmaster - reinstate monica

You have basically two options:

您基本上有两种选择：

1. You merge. That is actually quite simple, and a perfectly local operation:

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

   This leaves the history exactly as it happened: You forked from master, you made changes to all branches, and finally you incorporated the changes from master into all three branches.

   gitcan handle this situation really well, it is designed for merges happening in all directions, at the same time. You can trust it be able to get all threads together correctly. It simply does not care whether branch b1merges master, or mastermerges b1, the merge commit looks all the same to git. The only difference is, which branch ends up pointing to this merge commit.

2. You rebase. People with an SVN, or similar background find this more intuitive. The commands are analogue to the merge case:

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

   People like this approach because it retains a linear history in all branches. However, this linear history is a lie, and you should be aware that it is. Consider this commit graph:

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

   The merge results in the true history:

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

   The rebase, however, gives you this history:

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

   The point is, that the commits E', F', and G'never truly existed, and have likely never been tested. They may not even compile. It is actually quite easy to create nonsensical commits via a rebase, especially when the changes in masterare important to the development in b1.

   The consequence of this may be, that you can't distinguish which of the three commits E, F, and Gactually introduced a regression, diminishing the value of git bisect.

   I am not saying that you shouldn't use git rebase. It has its uses. But whenever you do use it, you need to be aware of the fact that you are lying about history. And you should at least compile test the new commits.

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'从未真正存在过，并且可能从未经过测试。他们甚至可能无法编译。它实际上是很容易通过重订创建无意义的提交，尤其是当变化master是在发展的重要b1。

   这样做的结果可能是，你无法分清哪三个提交的E，F和G实际上引入了回归，减少的价值git bisect。

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

回答by Michael J. Gray

git rebase masteris the proper way to do this. Merging would mean a commit would be created for the merge, while rebasing would not.

git rebase master是正确的方法来做到这一点。合并意味着将为合并创建一个提交，而变基则不会。

回答by Simon Bingham

If you've been working on a branch on-and-off, or lots has happened in other branches while you've been working on something, it's best to rebase your branch onto master. This keeps the history tidy and makes things a lot easier to follow.

如果您一直在断断续续地处理一个分支，或者在您处理某事时在其他分支中发生了很多事情，最好将您的分支重新设置为 master。这使历史保持整洁，并使事情更容易遵循。

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

Notes:

笔记：

• Don't rebase branches that you've collaborated with others on.
• You should rebase on the branch to which you will be merging which may not always be master.

• 不要对你与其他人合作过的分支进行 rebase。
• 您应该基于要合并的分支，该分支可能并不总是主分支。

There's a chapter on rebasing at http://git-scm.com/book/ch3-6.html, and loads of other resources out there on the web.

在http://git-scm.com/book/ch3-6.html上有一章是关于变基的，网上还有很多其他资源。

回答by bluemoon

@cmaster made the best elaborated answer. In brief:

@cmaster 做出了最详尽的回答。简单来说：

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

You should not rewrite branch history instead keep them in actual state for future references. While merging to master, it creates one extra commit but that is cheap. Commits does not cost.

您不应该重写分支历史记录，而是将它们保持在实际状态以备将来参考。在合并到 master 时，它会创建一个额外的提交，但这很便宜。提交不花钱。

回答by Sundar Gsv

To update other branches like (backup) with your master branch copy. You can do follow either way (rebase or merge)...

使用您的主分支副本更新其他分支，例如（备份）。您可以按照任何一种方式进行操作（变基或合并）...

1. Do rebase(there won't be any extra commit made to the backup branch).

2. Merge branches(there will be an extra commit automatically to the backup branch).

   Note : Rebase is nothing but establishing a new base (a new copy)

1. 执行 rebase（不会对备份分支进行任何额外的提交）。

2. 合并分支（会有一个额外的自动提交到备份分支）。

   注意：Rebase 只不过是建立一个新的基础（一个新的副本）

git checkout backup
git merge master
git push

git checkout backup
git merge master
git push

(Repeat for other branches if any like backup2 & etc..,)

（如果有任何像backup2等，请重复其他分支，）

git checkout backup
git rebase master
git push

git checkout backup
git rebase master
git push

(Repeat for other branches if any like backup2 & etc..,)

（如果有任何像backup2等，请重复其他分支，）

回答by Brian Agnew

You can merge, or you can apply individual commits across branches by using git cherry-pick.

您可以合并，也可以使用git cherry-pick跨分支应用单个提交。

回答by kris

There are two options for this problem.

这个问题有两种选择。

1) git rebase

1) git rebase

2) git merge

2) git 合并

Only diff with above both in case of merge, will have extra commit in history

在合并的情况下，只有与上述两者的差异，才会在历史记录中进行额外的提交

1) git checkout branch(b1,b2,b3)

1) git checkout 分支(b1,b2,b3)

2) git rebase origin/master (In case of conflicts resolve locally by doing git rebase --continue)

2) git rebase origin/master (如果发生冲突，通过执行 git rebase --continue 在本地解决)

3) git push

3) git 推送

Alternatively, git merge option is similar fashion

或者， git merge 选项是类似的方式

1) git checkout "your_branch"(b1,b2,b3)

1) git checkout "your_branch"(b1,b2,b3)

2) git merge master

2）git合并主

3) git push

3) git 推送

回答by D_Oghli

to update your branch from the master:

从主更新你的分支：

  git checkout master
  git pull
  git checkout your_branch
  git merge master