3

我的十几个开发人员团队以滚动发布模式开发了一个 Web 应用程序：一旦某些功能集准备就绪，高级开发人员会对其进行审查，然后将其推送到 QA 系统中，然后再推送到生产系统中。这通常在每个工作日发生几次。

当前使用的 VCS 是 SVN，向 QA 和生产系统的推送是通过一个奇怪的内部部署工具完成的，该工具在 SVN 上工作，但基于文件（因此，如果您需要推送文件 X 的新版本，并且 X 已从其他一些您不想推送的变更集中取消推送更改，您有问题）。

我计划为切换到 Git 进行宣传，所以我在考虑工作流的样子。由于我们没有版本化版本，因此通常链接的成功 Git 分支模型等常见建议不适用。

问题 1：是否有任何文档化的工作流程我可以查看以获得更多灵感，类似于上面链接的工作流程，这些工作流程针对滚动发布进行了优化？或者你会推荐一个？

我试图在纸上建模一个工作流，它像往常一样使用功能分支和主控，并且有更多的分支来反映 QA 和生产服务器的状态。（一个只会从master合并到那里。）

我无法克服的问题是master中的某些东西由于某种原因没有准备好发布。例如，假设功能分支foo被认为已完成，合并到master并推送到qa分支。然后功能分支栏也会发生同样的情况。现在在 QA 系统上，我们发现foo已损坏，需要更多开发，而bar已准备好推入生产系统。但是master上没有提交，其中包括bar，但不包括foo，那么我们应该推送什么？唯一想到的是恢复合并提交将foo转换为master。（在链接后面，Linus 解释了恢复合并提交的几个问题。）

问题2：知道如何更优雅地克服这个问题吗？

4

4 回答 4

4

不要忘记，使用 DVCS，您不仅有合并的工作流程，还有repos 之间的发布（推/拉）工作流程。

master在评估功能时，您不必影响您的存储库。
您可以推送到feature单独的 QA 存储库的分支。

  • 如果测试通过，则QA/master更新，所有开发人员都可以master从 QA 中提取以更新他们的 master，同时继续开发其他功能（他们将feature在更新的基础上重新设置本地分支master）。
  • 如果测试失败，QA/master则不受影响。
于 2013-01-27T20:49:42.773 回答
4

到目前为止，我使用的工作流程非常成功：

  • 每个开发人员都致力于他们的功能/修复

  • 一旦他们对工作感到满意，他们就会将分支推送到远程

    git push -u origin 新功能

  • QA 或测试 [服务器 | 人 | team] 拉取 master 和要发布的功能分支，并将其合并到 master 但不推送到远程

  • 一旦功能被 QA'ed 它与 --no-ff 合并并推送到 master

  • 现在可以删除功能分支

    git 推送来源：新功能

  • 实时服务器总是从主服务器拉取

对我们来说，这可以确保实时服务器包含当前“最佳”代码的滚动发布。

如果您对分支模型感兴趣，我发现这非常有用： nvie.com/posts/a-successful-git-branching-model/

于 2013-06-06T18:41:54.960 回答
1

git 主页上有工作流的文档

于 2013-01-27T20:53:01.833 回答
0

这是一个不错的幻灯片，值得您自己思考。没有什么是完美的，尽量满足你的需求。

发布管理 Git 工作流

https://speakerdeck.com/ewoodh2o/release-management-git-workflow

于 2013-08-14T08:54:39.083 回答