我目前正在使用GIT进行python项目，我们有两个分支master和release。新功能将提交给主分支，而错误修复仅针对发布分支。
我的问题是将错误修复从发布分支迁移到主分支的最佳方法是什么。
我能想到的两种方法是做一次改变，但这对我来说从未真正起作用。我想到的另一种方法是做樱桃，但这将是乏味的。我的一位同事告诉我，我可以将主分支的起源改为其他一点，但我真的不知道他的意思。
我想知道有哪些替代品可用，目前的最佳做法/确定的火灾方式是什么。如果您还可以发布命令或指出一些示例，我将不胜感激。
提前致谢， NAV
答案 0 :(得分：1)
通常您只需将发布分支合并到开发分支中。
在典型的工作流程中，发布分支从开发分支分支出来。如您所述，新开发提交已添加到开发分支，并且修补程序将添加到发布分支。在某些时候，您将在发布分支中进行开发分支合并，即开发分支获得新的合并提交，并且开发分支头（主）前进，而发布分支头保持不变。
$ git checkout master
$ git merge -m "Merge in hotfix for 'blah blah blah' back into develop" release
开发分支现在将包含新的开发提交和修补程序，而release分支仍然只包含修补程序。您可以继续向发布分支添加其他修补程序，并让开发合并它们（以及继续将开发工作提交到开发分支）。
gitflow图片显示了这一点：
这种方法不允许您选择合并哪些修补程序进行开发（除非您专门为排除某些提交而执行某些操作）。请记住，当一个分支在另一个分支中合并时，第一个分支有效地从第二个分支（从第二个分支的合并点返回）获得第一个分支尚未拥有的所有提交，即它获取所有提交的分支。发布分支后，它从以前没有合并到开发中的开发中分离出来。如果您在发布时制作了2个修补程序，但没有合并第一个，但是在第二个修补程序之后选择在发布分支的提示中进行开发合并，开发将获得这两个修补程序。
-
在开发分支中您可能不需要的唯一修补程序更改包括碰撞版本＃。您需要在合并期间（或之后）修复它，或者确保在发布分支中的单独提交中隔离这些更改，以便您可以“伪造”单独提交的合并回到开发分支，即make开发分支认为它已经具有该提交而没有实际合并该提交的“差异”。我粗略地描述了这个过程：
https://stackoverflow.com/a/19794987/11296
例如，如果您在发布分支上执行错误修复，然后在单独的提交（最后一次提交）中更新文档/代码中的版本＃，则将其合并到开发分支中，如下所示：
$ 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
答案 1 :(得分：0)
做一个rebase实际上是连续做了一堆樱桃选择 - 这就是rebase脚本在底层调用的内容。
如果我了解你，可能有也可能没有一些共同的祖先点，R，其中主人和释放是相同的。随后，功能和修复程序已添加到master中，而只添加了一些关键修复程序以进行发布：
R <- feat <- feat <- fix <- feat <- fix <- feat [master]
\
\
<- fix <- fix <- fix [release]
如果是这种情况，您希望将发布分支的MOST重新绑定到主服务器上（可能存在“解决生产问题的”恐慌修复“，但您不想保留）。
Rebase是实现这一目标的方法。看看关于变基的git书章节，并继续阅读它，直到你得到它告诉你的东西。 （http://git-scm.com/book/en/Git-Branching-Rebasing）
特别是，您希望了解自动变基和交互式变基。使用交互式rebase使您有机会“删除”您不想移动的更改。这是“恐慌修复”问题的解决方案。