Git 将修补程序合并到多个分支

Git merging hotfix to multiple branches

提问by Chuck M

I've been trying to wrap my head around git branching models. I've been looking at http://nvie.com/posts/a-successful-git-branching-model/for some ideas and coming from Subversion one thing I was really looking forward to was making a change in a single place and merging it to all the branches that needed it. In Subversion, we ended up doing to much copy of code around.

我一直在努力思考 git 分支模型。我一直在查看http://nvie.com/posts/a-successful-git-branching-model/以获得一些想法并且来自 Subversion 我真正期待的一件事是在一个地方进行更改将它合并到所有需要它的分支。在 Subversion 中，我们最终做了大量的代码副本。

However I still don't get this completely. Here is a standard type of workflow that I have and it will always come up with conflicts.

但是我仍然没有完全理解这一点。这是我拥有的一种标准类型的工作流程，它总是会出现冲突。

# create new version branch
git checkout master
git checkout -b v3
vim pom.xml  # change branch version to "3.1-SNAPSHOT"
git commit -a
git checkout master
vim pom.xml  # change master version to "4.0-SNAPSHOT"
git commit -a

So the master is at 4.0-SNAPSHOT and the branch is at 3.1-SNAPSHOT.

所以master在4.0-SNAPSHOT，分支在3.1-SNAPSHOT。

Not I want to create a hotfix on the branch and move it to the trunk.

不是我想在分支上创建一个修补程序并将其移动到主干。

git checkout v3
git checkout -b hotfix
vim file.txt  # make a bugfix change
git commit -a
git checkout v3
git merge hotfix  # this works fine
git checkout master
git merge hotfix  # this has a conflict since both branches have changed the version

I understand why its happening and it makes sense. Is there a better way of doing this?

我明白为什么会发生这种情况，而且这是有道理的。有没有更好的方法来做到这一点？

I read about cherry-pick, which I tested and does work:

我读了关于cherry-pick的文章，我测试过它确实有效：

git checkout v3
git cherry-pick a518b0b75eaf28868
git checkout master
git cherry-pick a518b0b75eaf28868

However, that doesn't seem like the "correct" way to handle this. Any suggestions?

但是，这似乎不是处理此问题的“正确”方法。有什么建议？

采纳答案by gahooa

Really, your answer is dependant on if you want your trees to be based on the same history... For example, 4.0 is based on the latest 3.X + all of the changes in 4.0...

真的，你的答案取决于你是否希望你的树基于相同的历史......例如，4.0 基于最新的 3.X + 4.0 中的所有更改......

Personally, I don't recommend it once you decide to start a new branch(s) for a new version(s). At a give point of time, the software is taking a different direction, so your branches should also.

就个人而言，一旦您决定为新版本启动一个新分支，我就不推荐它。在给定的时间点，该软件正朝着不同的方向发展，因此您的分支机构也应该这样做。

This leaves git cherry-pickas your ideal solution. Make the change in whatever branch makes the most sense, and then cherry pick it to the older versions. This is the same as if you had checked out the old branch and manuallyapplied the same change, and made a new commit. It keeps it clean and to the point.

这将git cherry-pick成为您的理想解决方案。在最有意义的任何分支中进行更改，然后将其挑选到旧版本。这与您已检出旧分支并手动应用相同更改并进行新提交相同。它保持清洁，切中要害。

Git merge or rebase are going to try to integrate the branches history together, each in their own way, which I suspect you don't want when backporting bug fixes, etc...

Git merge 或 rebase 将尝试以自己的方式将分支历史记录集成在一起，我怀疑您在向后移植错误修复等时不希望这样做......

回答by ellotheth

If you wanted to get super-technical about it, you could create the hotfix from a common ancestor:

如果您想获得关于它的超级技术，您可以从一个共同的祖先创建修补程序：

git merge-base v3 master
git checkout -b hotfix <whatever you got from merge-base>
# make your fix
git checkout v3 && git merge --no-ff hotfix
git checkout master && git merge --no-ff hotfix

        v3--------v3 (hotfixed)
       /         /
ancestor----hotfix
       \         \
        master----master (hotfixed)

The --no-ffflag is there to highlight that Git will create a merge commit, keeping the hotfixbranch label at the hotfix tip, instead of pulling the label to v3or master. (You can omit the flag and get the same behavior, since the hotfixbranch has one commit that isn't in masteror v3. More info in the docs.)

该--no-ff标志用于强调 Git 将创建合并提交，将hotfix分支标签保留在修补程序提示处，而不是将标签拉到v3或master。（您可以省略标志并获得相同的行为，因为该hotfix分支有一个不在masteror 中的提交v3。文档中的更多信息。）

Personally, I think that's overkill. I'd go with gahooa: make the hotfix on the branch that makes sense, then merge or cherry-pick depending on how you want the branches to relate to each other.

就个人而言，我认为这太过分了。我会选择 gahooa：在有意义的分支上制作修补程序，然后根据您希望分支相互关联的方式进行合并或挑选。

回答by Ale? Kotnik

In the case, you are working on branch "4.0" and have to make a fix on "3.1", you may rebase "4.0" after you commit "3.1":

在这种情况下，您正在处理分支“4.0”并且必须对“3.1”进行修复，您可以在提交“3.1”后重新调整“4.0”：

Make sure you are on the feature branch 4.0:

确保您在功能分支 4.0 上：

git checkout 4.0

Save current work so you can check out other branch:

保存当前工作，以便您可以查看其他分支：

git stash  
git checkout 3.1  

Do editing and commit:

进行编辑和提交：

git commit -a -m "bug fix"  
git checkout 4.0  

Get back your changes:

取回您的更改：

git stash apply  

Change 4.0 so it branches of the current head of "3.1":

将 4.0 更改为“3.1”当前头部的分支：

git rebase "3.1"

回答by Mark

I've been struggling with this question, too, and I think if you're willing to change your versioning strategy a little (i.e., depart from the -SNAPSHOT versions that Maven encourages), this could be solved by using a fixed version (like SNAPSHOT or 0.0.0-SNAPSHOT) on master (or whatever your development branch is). (The SNAPSHOT suffix is important, if you're using Maven, since Maven treats SNAPSHOT-versioned artifacts differently than others.)

我也一直在为这个问题苦苦挣扎，我认为如果你愿意稍微改变你的版本控制策略（即，偏离 Maven 鼓励的 -SNAPSHOT 版本），这可以通过使用固定版本来解决（像 SNAPSHOT 或 0.0.0-SNAPSHOT）在 master 上（或任何你的开发分支）。（如果您使用 Maven，则 SNAPSHOT 后缀很重要，因为 Maven 对待 SNAPSHOT 版本化工件的方式与其他工件不同。）

In fact, I think you'd want to institute a policy of only ever changing the version number on your production branch (the one from which you build releases) or on branches which are for release purposes only (e.g., changing version numbers) and which you never intend to merge back to the development branch.

事实上，我认为您希望制定一项政策，只更改您的生产分支（您从中构建发布的分支）或仅用于发布目的的分支（例如，更改版本号）和您从不打算将其合并回开发分支。

I haven't actually used this strategy yet, but was just thinking about it, and I think I'll start trying it.

我还没有真正使用过这个策略，只是在考虑它，我想我会开始尝试它。