26

我一直试图围绕 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

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

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

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

我理解它为什么会发生，这是有道理的。有没有更好的方法来做到这一点？

我读到了cherry-pick，我对其进行了测试并且确实有效：

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

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

4

4 回答 4

28

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

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分支标签保留在修补程序提示处，而不是将标签拉到v3or master。（您可以省略该标志并获得相同的行为，因为该hotfix分支有一个不在masteror中的提交v3。更多信息在文档中。）

就个人而言，我认为这是矫枉过正。我会选择 gahooa：在分支上制作有意义的修补程序，然后根据您希望分支如何相互关联来合并或挑选。

于 2012-05-25T21:58:05.137 回答
13

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

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

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

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

于 2012-05-25T21:16:44.513 回答
1

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

确保您在功能分支 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"
于 2012-05-25T21:12:02.200 回答
0

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

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

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

于 2015-07-31T19:46:27.663 回答