从 master 更新 Git 分支答案

【问题标题】：Update Git branches from master从 master 更新 Git 分支
【发布时间】：2011-04-22 01:49:51
【问题描述】：

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

我有四个分支（master、b1、b2 和 b3）。
在完成 b1-b3 工作后，我意识到我需要对分支 master 进行一些更改，而这些更改应该在所有其他分支中进行。
我在master 中更改了我需要的内容，然后...这是我的问题：

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

【问题讨论】：

我在这里找到了答案：How do you merge selective files with git-merge?
又一个简单的任务被 Git 搞定了。 Git 开发人员应该在他们的 SDLC 循环中使用 Stack Overflow 作为反馈。 300,000 人应该指出 Git 的工作流程存在严重问题。他们需要聘请 UX 专家，因为他们显然无法独自完成。

标签： git git-branch

【解决方案1】：

如果您想恢复到上次提交并同时删除日志历史记录

使用下面的命令假设你想去之前的提交，它有 commitID SHA - 71e2e57458bde883a37b332035f784c6653ec509 你可以指向这个提交它不会在这个提交之后显示任何日志消息并且所有历史都将是之后就被删除了。

git push origin +71e2e57458bde883a37b332035f784c6653ec509^:master

【讨论】：

【解决方案2】：

你基本上有两种选择：

你合并。这实际上非常简单，而且是一个完美的本地操作：
```
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。它有它的用途。但是，无论何时使用它，您都需要意识到您在历史上撒谎的事实。你至少应该编译测试新的提交。

【讨论】：

我正在合并另一个源分支（不是主分支），添加到这个好答案的其他步骤是在合并之前在我的本地仓库上更新它（在本地拥有最新的代码）：git checkout <source branch>@ 987654342@。然后继续上面的：git checkout b1 ...
作为一个长期使用 SVN 的用户，我更喜欢合并选项而不是 rebase：使用任何版本控制，准确记录您所做的更改以及原因是非常非常重要的。我可以看到变基对简化明显历史的吸引力，但是您应该返回并添加到 E'、F'、G' 的提交 cmets - 并且最好将变基自动添加到这些 cmets。否则，如果 G' 上的构建/测试/测试部署过程中断，您必须找出在没有完整信息的情况下进行更改的原因。
历史是谎言
感谢我使用“git merge any-branch-name”将一个分支代码合并到另一个分支。当我在分支 2 上时，我可以在本地测试分支 1 的代码
或者你最终可能会遇到这种情况，从这种情况下，一个巨大的混乱（首先分支）$ git rebase production First, rewinding head to replay your work on top of it... Applying: ADDED TO ENV AS TEST Using index info to reconstruct a base tree... M Puppetfile Falling back to patching base and 3-way merge... Auto-merging Puppetfile CONFLICT (content): Merge conflict in Puppetfile Failed to merge in the changes. Patch failed at 0001 ADDED TO ENV AS TEST The copy of the patch that failed is found in: /home/user/src/puppet4-controlrepo/.git/rebase-apply/patch

【解决方案3】：

git checkout master
git 拉
git checkout feature_branch
git rebase master
git push -f

你需要在对 master 进行 rebase 后进行强力推送

【讨论】：

【解决方案4】：

从 master 更新你的分支：

  git checkout master
  git pull
  git checkout your_branch
  git merge master

【讨论】：

【解决方案5】：

这个问题有两种选择。

1) git rebase

2) git 合并

只有在合并的情况下与以上两者有差异，才会有额外的历史提交

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

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

3) git 推送

另外，git merge 选项也类似

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

2) git 合并大师

3) git 推送

【讨论】：

【解决方案6】：

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

做rebase（不会对备份分支进行任何额外的提交）。
合并分支（会有一个额外的自动提交到备份分支）。

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

git checkout backup
git merge master
git push

（如果有其他分支，如 backup2 等，请重复此操作）

git checkout backup
git rebase master
git push

（如果有其他分支，如 backup2 等，请重复此操作）

【讨论】：

【解决方案7】：

@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`

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

【讨论】：

是从 master 刷新一个特性分支，应该定期做些什么？假设功能分支需要一段时间才能完成，而 master 在那段时间已经进化了。

【解决方案8】：

你有两个选择：

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

结帐每个分支：

git checkout b1

然后合并：

git merge origin/master

然后推送：

git push origin b1

或者，你可以做一个变基：

git fetch
git rebase origin/master

【讨论】：

我担心这种方法。当我运行 git log --graph 时，图表显示 master 实际上已合并到主题分支。从长远来看，这会导致任何问题吗？我认为最好的做法是始终将主题分支合并回主分支。请发表评论。
如果您要使用合并工作流程，请注意此问题：randyfay.com/node/89
您正在将 master 合并到 b1。为什么你got push origin master... 没有意义。您没有更改主分支。我认为 119 upvote 是一个错误：/
不要使用合并方式，使用git rebase master是正确答案
对于我们这些稍后阅读的人 - @Kursion 对错字的担忧已通过作者的编辑得到解决。此外，下面第二高的答案与此答案基本相同，但带有分支结构图和关于您为什么不想变基的警告。

【解决方案9】：

如果您一直在断断续续地在一个分支上工作，或者在您处理某事时在其他分支上发生了很多事情，那么最好将您的分支重新定位到 master 上。这使历史保持整洁，并使事情更容易理解。

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 有一个关于变基的章节，以及网络上的大量其他资源。

【讨论】：

感谢您的简单解决方案
提示：如果您之前所在的分支是 local_branch_name，git checkout local_branch_name 可能是 git checkout -

【解决方案10】：

git rebase master 是执行此操作的正确方法。合并意味着将为合并创建一个提交，而变基则不会。

【讨论】：

当你已经推送到原点时，如果你变基，你将重写提交历史，这将与你的远程分支冲突。我认为 rebase 应该只在拉取或没有推送到远程分支时使用。
如果您是唯一一个在远程分支上工作的人，您可以执行 git push --force origin 功能来使用重新定位的本地分支更新您的远程分支。 stackoverflow.com/questions/8939977/…
rebase 并合并这两个作品，rebase 最适合私有分支，因为它提供了更清晰的历史图表。这个答案是最好的
需要更清楚地权衡清晰（对于单用户或小团队来说很好）或混乱的真相（对于多贡献者代码分支 - 可维护性所必需的（根据我的经验 - YMMV） ))。
re "如果你已经推送了怎么办？" --> The golden rule of git rebase is to never use it on public branches.

【解决方案11】：

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

【讨论】：