在git流模型中，我应该从master中的合并提交来构建版本吗？ [英] In the git flow model should I build from the merge commit in master to release?

问题描述

在我的公司，我们有一个CI / Build服务器，用于测试和构建版本（以及功能和开发分支）。
在 git flow 分支模型中，当您要释放时分支开发并命名它（例如）release-1.4。然后，CI / Build服务器将自动构建分支，并将其部署到临时服务器以进行手动集成测试。一旦我们对构建感到满意，我们就会部署它。但是在git流程分支模型中，我们需要首先将它合并为master和tag。问题是，我们是否需要在合并或者合并之后运行另一个构建和测试周期？

合并和标记结束标记指向一个不同的（技术上）提交比发布版建立。在我们进入主服务器后重建似乎也不好，因为那时我们会觉得不得不测试一下这个版本，以确保它也可以。

我已经来到的选项up：
$ b

• 在发布分支中构建，然后在主分支中合并并重新构建和测试
  
• 在发布分支中构建和测试，然后合并并相信不需要新的构建


• 修改git流模型以删除合并到master的步骤并仅标记最终落实在我们想要发布的发行版分支中。
  
  
  
  • 没有合并到主人会丢失什么？
  
  
  • 在这种情况下，我们可能只需在master中开发
  b
  
  $ b

  解决方案

  
  

  现在的问题是，我们是否需要在合并之后运行另一个构建和测试周期？或者什么？
  

  合并不应该破坏任何东西，因为它应该作为一个快进合并，所有对master的提交都在release分支上。因此，您不能在master post-merge上创建一个不在发布分支上的bug。

  
  
  

  所以从技术上讲，这不是您建立的确切提交但哲学是主分支上的每件东西都在生产中。在任何时候，如果有人拉主分支，他应该得到当前的生产代码。这就是为什么你不合并，然后构建，测试，等待，并修复一个版本的主人。

  
  
  

  现在事情并不总是顺利。在发布版本已经过验证并准备发布时，您可能会遇到需要修补程序的主要生产错误，在这种情况下，一些提交已被推到掌握并开发，而不是发布分支。如果发生这种情况，我会重新分配（在团队中工作时小心，合并更安全）开发分支（以赶上修补程序）并重新重建。总而言之，如果在发布分支的创建时间和验证时间之间没有修补程序，则不需要重新构建。

  
  

  At my company we have a CI/Build server that we use to test and build releases (as well as features and the develop branch). In the git flow branching model when it is time to release you branch off develop and name it (for instance) release-1.4. The CI/Build server would then automatically build the branch and we would deploy it to a staging server for manual integration testing. Once we are satisfied with the build we would like to deploy it. But in the git flow branching model we need to merge to master and tag first. The question is, do we need to run another build and test cycle after this merge or what?

  It seems weird to merge and tag ending up with the tag pointing at a different (technically) commit than the release was built off of. It also seems bad to rebuild after we get into master because we would then feel compelled to test that build to make sure it is ok too.

  The options I've come up with are:

  • build in the release branch and then merge and rebuild and test in the master branch
  • build and test in the release branch then merge and trust that no new build is needed
  • Modify the git flow model to remove the step of merging to master and just tag the final commit in the release branch that we want to release.
    • What would be lost by not merging to master?
    • In this case we could probably just develop in master

  解决方案

  The question is, do we need to run another build and test cycle after this merge or what?

  That merge shouldn't break anything because it should be a fast-forward merge, all the commits on master are on the release branch. Therefore, you can not create a bug on master post-merge that wasn't on the release branch.

  So technically yes, it isn't the precise commit you built, but the philosophy is that everything on the master branch is in production. At anytime, if someone pulls the master branch he should get the current production code. That's why you don't merge and then build, and test, and wait, and fix things on master for a release.

  Now things does not always go smoothly. By the time the release has been validated and is ready to ship, you may have encounter major production bugs that needed a hotfix, in that case some commits have been pushed to master and develop but not to the release branch. If this happens, I'd rebase (be careful with that when working in team, merge is safer) the release branch on develop (to catch up with the hotfixes) and rebuild again. To sum up, if there are no hotfixes between the time the release branch was created and the time it is validated, no need to rebuild.

  这篇关于在git流模型中，我应该从master中的合并提交来构建版本吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！