将更改提交到 Git 中的多个分支
典型的使用场景:
我有master、branch_foo和branch_bar。全部都是最新的。现在,我做了一个“git checkout master”并致力于错误修复。
假设修复是在所有分支上处于相同状态的跟踪文件上 - 即。在修复之前,每个分支的文件差异不会导致任何差异。
有没有办法将此修复提交到所有分支?
Typical usage scenario:
I have master, branch_foo and branch_bar. All are up to date. Now, I do a "git checkout master" and work on a bug fix.
Lets say that fix was on a tracked file that is in the same state on all branches - ie. before the fix, a diff of the file from each branch results in no differences.
Is there a way to commit this fix to all branches?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
常见的方法是“向上合并”。来自 man gitworkflows :
第一种方法当然是首选 - 最好在您的存储库中只提交一次,并且能够查看它如何进入每个分支的历史记录。然而,生活并不完美,有时你会发现自己属于第二类。如果这种情况变得足够普遍,您也许可以编写一个脚本,
依次检查每个分支并挑选给定的提交。
The common approach to this is "merging upwards". From
man gitworkflows
:The first method is of course preferred - it's good to have a commit in your repo only once, and to be able to see the history of how it got into each branch. Life isn't perfect, though, and you'll sometimes find yourself in the second category. If that situation becomes common enough, you could perhaps write a script like
which checks out each branch in turn and cherry-picks the given commit.
我期望
gitcherry-pick< /code>
就是你想要的。
将修复提交到第一个分支后,您可以使用 gitcherry-pick 将其合并到其他每个分支中。
关于 SO 的相关问题可能会引起兴趣:
Git &在多个分支上工作
I expect
git cherry-pick
is what you want.After committing the fix to the first branch, you can use
git cherry-pick
to merge it into each of the other branches.This related question on SO may be of interest:
Git & Working on multiple branches
是的,有。在单独的主题(功能)分支上进行此提交(从最旧的分支/最早的状态分支),然后将此主题分支合并到您想要的任何分支。
此工作流程在 Junio C Hamano(Git 维护者)的 Never merging back 博客文章中进行了描述)。
这大致就是Jefromi写了写了
Yes, there is. Make this commit on separate topic (feature) branch (branching off oldest branch / earliest state), and then merge this topic branch into any branch you want.
This workflow is described for example in Never merging back blog post by Junio C Hamano (maintainer of Git).
That is roughly what Jefromi wrote wrote