我们目前正在使用SVN，但考虑转向Git以支持我们的新工作流程，该工作流程严重依赖于rebase。
我们正在考虑一个开发工作流程，其中每个单独的功能都在一个单独的分支上开发，然后在准备发布时合并到trunk / master中。在将分支合并回trunk / master后，它将始终被删除。
一个建议是使用git rebase来保持功能分支与master中的更改保持同步（因此我们可以在分支中测试将要发布的内容），并简化从分支的合并 - ＆gt;主
我们正在考虑的替代方案是使用svn merge来保持功能分支与trunk中的更改保持同步，然后使用svn merge --reintegrate将功能分支合并回trunk以便发布。
每种方法的差异和潜在缺陷是什么？哪个更适合我们的工作流程？
答案 0 :(得分：1)
这是git中非常简单的工作流程。一些开发人员使用您描述的一种或两种方法。
就个人而言，我是scott Chacon's strategy的粉丝并且发现它非常有用。
你可以使用rebase来保持主分支的线性历史记录，这是正常的，但它确实有一点点的可能性，只是从刚开始使用git的人那里抛出一些主要的循环。重新修改历史记录，如果不小心，可能会导致问题。
Git-merge（不是你注意到的svn-merge --reintegrate）如果你刚开始的话，在git中会更直接一些。 Git的合并策略经过深思熟虑，可以自动避免麻烦。
如果我正在开发功能分支然后将其合并到master中，我希望在master上运行git merge --no-ff feature以创建合并提交只是为了显式。
当你刚开始使用git时，我会选择合并工作流程。恕我直言，如果你来自svn背景，它会更直观。