将Git合并到多个分支 [英] Git merging hotfix to multiple branches

问题描述

我一直试图围绕git分支模型进行包装。我一直在寻找 http://nvie.com/posts/a-成功的git-branching-model / 对于一些想法和来自Subversion的一件事我真的很期待在一个地方做出改变并将它合并到所有需要它的分支。在Subversion中，我们最终做了大量的代码拷贝。

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

 ＃创建新版本分支
 git checkout master 
 git checkout -b v3 
 vim pom.xml＃将分支版本更改为3.1-SNAPSHOT
 git commit -a 
 git checkout master 
 vim pom.xml＃将主版本更改为4.0-SNAPSHOT
 git commit -a 
  

<所以主人在4.0-SNAPSHOT和分支在3.1-SNAPSHOT。

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

  git checkout v3 
 git checkout -b热修复
 vim file.txt＃ 
 git commit -a 
 git checkout v3 
 git merge hotfix＃this works fine 
 git checkout master 
 git merge hotfix＃这有冲突，因为两个分支都改变了版本
  

我理解它发生的原因以及它的意义。有没有更好的方法来做到这一点？

我读过关于cherry-pick的内容，我测试过并且确实有效：

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

然而，这看起来不像是正确的处理方式。任何建议？

解决方案

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

就个人而言，一旦您决定开始，我不会推荐它新版本的新分支。在一个给定的时间点，软件正在采取不同的方向，所以你的分支机构也应该这样做。

这留下 git cherry-pick 作为您的理想解决方案。在任何分支最有意义的地方做出改变，然后樱桃把它选到旧版本。这与您检出旧分支并手动应用相同更改并进行了新提交相同。它保持了整洁和重点。



Git合并或重新设计将尝试将分支历史整合到一起，每个都以自己的方式进行，我怀疑你不会不希望在反向移植错误修复程序等时使用。

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.

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.

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:

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?

解决方案

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...

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-pick as 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 manually applied the same change, and made a new commit. It keeps it clean and to the point.

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合并到多个分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！