我一直在试图环绕的Git分支模型我的头。 我一直在看http://nvie.com/posts/a-successful-git-branching-model/的一些想法，并从Subversion迁移过来的一两件事，我真的很期待是使在一个地方的变化，它合并到需要它的所有分支。 在Subversion，我们结束了围绕在做的代码更副本。
不过我还是没有完全得到这个。 这里是工作流程的标准型，我已经和它总是会拿出冲突。
# 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
所以法师是在4.0的快照和分支是在3.1快照。
不是我想创建的分支上的修补程序，并将其移动到主干。
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
我理解为什么它的发生，这是有道理的。 是否有这样做的更好的办法？
我读到摘樱桃，这是我测试，没有问题：
git checkout v3
git cherry-pick a518b0b75eaf28868
git checkout master
git cherry-pick a518b0b75eaf28868
然而，这似乎并不像“正确”的方式来处理这个问题。 有什么建议？
真的，你的答案是依赖，如果你想将基于相同的历史的树木...例如，4.0是基于最新的3.X +所有的在4.0的变化...
就个人而言，一旦你决定开始一个新的分支（个），一个新的版本（S）我不建议这样做。 在一个时间点给予，该软件采取了不同的方向，所以你的分支也应该。
这使得git cherry-pick为你的理想解决方案。 使任何分支是最有意义的变化，然后樱桃它拆了旧版本。 这是一样的，如果你已经签出的老枝，并手动应用了相同的变化，并作出了新的承诺。 它保持简洁，重点突出。
Git的合并或重订要去尝试的分支历史集成在一起，各自在自己的道路，我怀疑向后移植bug修复时，等你不想...
如果你想获得超技术的话，你可以创建从一个共同的祖先的修补程序：
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)
该--no-ff标志是有突出git会创建一个合并提交，保持hotfix分支标签在修补程序尖，而不是拉动标签v3或master 。 （可以省略标志，并获得相同的行为，因为hotfix分支有一个承诺，是不是在master或v3 。更多信息的文档 。）
就个人而言，我认为这是矫枉过正。 我会跟gahooa去：作出有意义的分支的修补程序，然后根据你想如何以树枝相互关联的合并或摘樱桃。
在这种情况下，你工作的分支“4.0”，并不得不做出的“3.1”的修复，你可以变基“4.0”你犯“3.1”之后：
请确保您的特性分支4.0：
git checkout 4.0
保存当前工作，这样你就可以检查出其他的分支：
git stash
git checkout 3.1
做编辑和提交：
git commit -a -m "bug fix"
git checkout 4.0
找回您的更改：
git stash apply
更改4.0所以它的“3.1”当前头的分支：
git rebase "3.1"
我已经疲于应付这个问题，太，我认为，如果你愿意改变你的版本策略一点（即从Maven的鼓励-SNAPSHOT版本出发日期），这可以通过使用固定版本（待解决像主快照或0.0.0-SNAPSHOT）（或者您的开发分支）。 （快照后缀是很重要的，如果你使用Maven，因为Maven的治疗快照版本的工件不同于别人。）
其实，我想你会想研究所只有不断变化对生产分支（可用于构建释放一个）或分支是仅发行目的版本号的政策（例如，改变版本号）和你从来没有打算合并回开发分支。
我还没有实际使用这种策略还，但只是在想这件事，我想我会开始尝试它。
