logo标签列表

是否有适用于滚动发布 Web 应用程序的 Git 工作流程？

gitworkflowrelease-management
3
我的团队有大约十几名开发人员，按照滚动发布模式制作Web应用程序：一旦某个功能集准备好，就由高级开发人员进行审核，并推入QA系统，然后再进入生产系统。这通常每个工作日会发生多次。
目前使用的版本控制系统是SVN，而推送到QA和生产系统则是使用一个奇怪的内部部署工具完成的，它可以在SVN上工作，但是基于文件（因此，如果您需要推送X文件的新版本，并且X文件有来自其他变更集的未推送更改，而您不想立即推送它们，则会出现问题）。
我计划宣传转换到Git，所以我正在考虑如何设计工作流程。像经常链接的成功的Git分支模型之类的通常建议并不适用于我们没有版本化发布的情况。
问题1：是否有任何已记录的工作流程可供进一步参考，类似于上面链接的工作流程，专门针对滚动发布进行优化？或者您建议采用哪种方式？

我尝试在纸上建模一个工作流程，使用特性分支和常规的master，并且有进一步的分支来镜像QA和生产服务器的状态。（只能从master合并到这里。）

我无法克服的问题是，当master中的某些内容由于某种原因不适合发布时。例如，假设功能分支foo被认为完成，合并到master并推送到qa分支。然后同样的事情发生在功能分支bar上。现在，在QA系统上，我们发现foo已经损坏，需要更多的开发，而bar已经准备好推送到生产系统。但是，在master上没有包含bar但不包含foo的提交，那么我们应该推送什么呢？唯一想到的是撤销将foo合并到master的提交。（在链接后面，Linus解释了撤销合并提交时遇到的几个问题。） 问题2：有什么更优雅的方法来解决这个问题吗？
4个回答
4

请不要忘记，使用分布式版本控制系统 (DVCS)，你拥有的不仅是合并工作流程，而且还有 repos 之间的发布工作流程(push/pull)。

在评估功能时，您不必影响您的仓库的 master 分支。
您可以将其推送到一个独立 QA 仓库的 feature 分支。

  • 如果测试通过，则会更新 QA/master，所有开发人员都可以从 QA 拉取 master 以更新他们的主干，同时继续开发其他功能（他们会将本地的 feature 分支变基于他们的更新过的 master）。
  • 如果测试失败，则不会更改 QA/master。
特性分支在QA存储库上不起作用，因为这是一个Web应用程序：服务器上一次只能运行一个状态。 - Stefan Majewsky
1
@StefanMajewsky 但是你可以同时运行多个版本的网站（在多个HTTP服务器上，其中一个专门用于QA）。 - VonC
4
以下是我迄今为止使用的工作流程：

  • 每个开发人员都在其特性修复/功能上开发

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

    git push -u origin newfeature

  • QA或测试[服务器|人员|团队]从主分支和您要发布的特性分支中拉取，并将其合并到主分支中，但不推送到远程

  • 一旦功能经过QA测试，它将以 -no-ff 合并，并推送到主分支

  • 可以删除特性分支

    git push origin :newfeature

  • 实时服务器始终从主分支中提取

对于我们来说，这确保了现场服务器包含当前“最佳”代码的滚动版本。
如果您对分支模型感兴趣，我认为这很有用：nvie.com/posts/a-successful-git-branching-model/
1
有趣。+1。不要忘记，你只需要一次git push -u origin xxx。之后，一个git push（不添加参数）就足够了：https://dev59.com/dm025IYBdhLWcg3wT0Hq - VonC
1
这是我们团队最终采用的模型。master 是生产服务器的状态，QA 服务器通过一个 UI 合并一组特性分支（该 UI 的使用仅限高级开发人员）。 - Stefan Majewsky
1

在git主页上有关于工作流程的文档。

请问您能否更精确地提供那个链接？ - Stefan Majewsky
@StefanMajewsky, http://git-scm.com/about/distributed 对工作流程有一些讲解，git书籍（http://git-scm.com/book）中有一章专门介绍此内容。还有其他关于git的书籍，只是不在线上。 - vonbrand
0
@Chaosekie 感谢您的编辑。比之前更好了。 - Jinzhao Huo
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接