从GIT中的一个分支迁移到另一个分支的替代方案

Question

我目前正在使用GIT开发一个python项目，并且我们有两个分支master和release。新功能致力于主分支，同时单独修复错误版本分支。

我的问题是将错误修复从发布分支迁移到主分支的最佳方式是什么。

我能想到的两种方法是做一个rebase，但是这对我来说从来没有真正奏效。我想到的另一种方法是做挑剔的，但这将是单调乏味的。我的一位同事告诉我，我可以将主分支的起源更改为其他点，但我不知道他的意思。

我想知道有什么替代品可供选择，以及目前最佳做法/确实如此的做法。如果你也可以发布命令或者指点一些例子，我将不胜感激。

由于提前， 导航

Answer 1

通常情况下，您只需将发布分支合并到开发分支中即可。

在典型的工作流程中，发布分支从开发分支分支出来。如您所描述的，新的开发提交被添加到开发分支，并且修补程序被添加到发布分支。在某一时刻，您将在发布分支中合并开发分支，即开发分支获得新的合并提交，并且在释放分支头部保持不变的情况下开发分支头部（主控）前进。

$ git checkout master 
$ git merge -m "Merge in hotfix for 'blah blah blah' back into develop" release 

开发分支现在将包含新的开发提交和修补程序，而发布分支仍然只包含修补程序。您可以继续向发布分支添加其他修补程序，并让开发将它们合并（并继续将开发工作提交给开发分支）。

的gitflow图片有这个可视化：

• http://nvie.com/posts/a-successful-git-branching-model/

这种方法不会让你选择哪一个修补程序得到重新合并开发（除非你做一些专门排除某些提交）。请记住，当一个分支合并到另一个分支中时，第一个分支有效地从第一个分支尚未拥有的第二个分支（从第二个分支的合并点）开始提交所有提交，即它获取所有提交它从以前没有被开发出来的开发中解除了分支。如果您在发行版上创建了2个修补程序，并未将第一个修补程序合并，但是随后在第2个修补程序之后选择在发布分支的提示中进行开发合并，那么开发将获得两个修补程序。

-

，你可能不希望在开发分支唯一的修补程序的变化是一样颠簸的版本号的变化。您将需要在合并（或之后）期间修复该问题，否则请确保在发布分支中的单独提交中隔离这些更改，以便您可以“伪造”将该提交单独合并回开发分支，即，使开发分支认为它已经有了这种承诺，而没有实际纳入该承诺的“差异”。我大致描述这里的过程：

https://stackoverflow.com/a/19794987/11296

例如，如果你在发布分支一个bug修正，然后更新的文档版本＃/在一个单独的代码提交（最后一次提交），然后合并到这样的开发分支：

$ git checkout release 
$ <implement bugfix> 
$ git add ... 
$ git commit -m "bugfix for ..." 
$ <change the version #> 
$ git commit -m "bump version number to ..." 

$ # Ready to pull this bugfix into development 
$ git checkout master 
$ # Merge in the bugfix changes (i.e. all but the last commit) 
$ git merge -m "Merge in hotfix for 'blah blah blah' back into develop" release^ 
$ # "Fake" merge the version # change 
$ git merge --strategy=ours -m "Fake merge version # change" release 

Answer 2

做一个变基基本上做了一堆樱桃挑选的一排 - 这是引擎盖下底垫脚本调用什么。

如果我了解你，可能有也可能不存在一些共同的祖先点R，其中主控和版本相同。随后，功能和修复已被添加到主，而仅加入关键修复发布：

R <- feat <- feat <- fix <- feat <- fix <- feat [master] 
\ 
    \ 
    <- fix <- fix <- fix [release] 

如果是这样的话，你最想要发布分支的衍合到主（有可能是“恐慌修复“你为解决生产问题而做的，但你不想保留）。

Rebase是要走的路。看看重新贴上git书的章节，并继续阅读它，直到你得到它告诉你的。 （http://git-scm.com/book/en/Git-Branching-Rebasing）

特别是，您希望了解自动重新结合和交互式结合。使用交互式底图可以让您有机会“放弃”您不想移动的更改。这是“恐慌修复”问题的解决方案。