我的团队由大约十几位开发人员在滚动发布模型中生成一个Web应用程序：一旦某个功能集准备就绪，它将由高级开发人员审核并推入QA系统，然后进入生产系统。这通常每个工作日发生几次。
当前使用的VCS是SVN，推送到QA并且生产系统是使用奇怪的内部部署工具完成的，该工具在SVN上运行，但是基于文件（所以如果你需要推送新版本的文件X，X已从其他一些您不想推送的变更集中删除了更改，但是您遇到了问题。）
我计划传播转换为Git，所以我在考虑工作流程的样子。由于我们没有版本化版本，因此通常的建议（例如经常链接的Successful Git branching model）不适用。
问题1：我是否有任何文档化的工作流程可供我们进一步了解，类似于上面链接的那些，这些工作流程针对滚动版本进行了优化？或者你会建议一个吗？
我试图在纸上建模工作流程，它像往常一样使用功能分支和主，还有更多分支，它们反映了QA和生产服务器的状态。 （只能在 master 中合并。）
我无法克服的问题是 master 中的某些内容由于某种原因未准备好发布。例如，假设功能分支 foo 被认为已完成，已合并到 master 并被推送到 qa 分支。然后，功能分支 bar 也会发生同样的情况。现在在QA系统上，我们发现 foo 已损坏并需要更多开发，而 bar 已准备好推入生产系统。但是 master 没有提交，其中包括 bar ，而不是 foo ，那么我们应该推送什么呢？我唯一想到的是{em> foo revert the merge commit到 master 。 （在链接的后面，Linus解释了恢复合并提交的几个问题。）
问题2：任何想法如何更优雅地克服这个问题？
答案 0 :(得分：4)
不要忘记，使用DVCS，在回购之间you don't have just a workflow of merge, but a workflow of publication（推/拉）。
在评估功能时，您不必影响回购的master
您可以推送到单独的QA回购的feature分支。
QA/master会更新，所有开发人员都可以从质量检查中提取master以更新其主人，同时继续开发其他功能（他们会重新定位其本地feature }更新master之上的分支。QA/master不受影响。答案 1 :(得分：4)
到目前为止，我使用的工作流程取得了巨大成功：
一旦他对工作感到满意，他就会把分支推到远程
git push -u origin newfeature
QA或测试[server |人| team]拉出你要发布的master和feature分支，并将它合并到master中但不会推送到远程
现在可以删除功能分支
git push origin：newfeature
实时服务器总是来自主
对于我们来说，这可以确保实时服务器包含当前“最佳”代码的滚动版本。
如果您对分支模型感兴趣，我发现这非常有用： nvie.com/posts/a-successful-git-branching-model/
答案 2 :(得分：1)
答案 3 :(得分：0)
这是一个值得自己思考的漂亮幻灯片。没有什么是完美的，尽可能地满足您的需求。
发布管理Git工作流程
https://speakerdeck.com/ewoodh2o/release-management-git-workflow