Git 工作流和发布分支：许多、一个还是无？

Git Workflow and Release Branches: Many, One, or None?

提问by Ron Garrity

For our web development, we have daily to weekly deployments. There are instances where we deploy something to QA, but they don't get around to testing it for a few days, and then we have a production fix or a new enhancement that needs to go out. Two questions:

对于我们的 Web 开发，我们每天到每周都有部署。在某些情况下，我们向 QA 部署了一些东西，但他们几天没有时间测试它，然后我们有一个生产修复或需要推出的新增强。两个问题：

(1) What would be a good workflow for this?

(1) 什么是好的工作流程？

(2) What are the advantages and disadvantages to having one continuous, long lived branch called production or release, as opposed to a new release branch for each release, or just doing everything out of master and tagging it accordingly? Again, this is for web development with frequent releases that can get backed-up.

(2) 拥有一个称为生产或发布的连续的、长期存在的分支，而不是为每个发布创建一个新的发布分支，或者只是在 master 之外做所有事情并相应地标记它，有什么优点和缺点？同样，这适用于可以备份的频繁发布的 Web 开发。

回答by Alexis

I'm not quite sure I understand your problem correctly, but my situation is similar to yours and I used (modification of) the following approach: http://nvie.com/posts/a-successful-git-branching-model/

我不太确定我是否正确理解您的问题，但我的情况与您类似，我使用（修改）以下方法：http: //nvie.com/posts/a-successful-git-branching-model/

In short, it's about having 2 main branches (masterand develop) and several types of supporting branches (feature, releaseand hotfixones). Speaking about your case, you would probably deploy to QA your releasebranches and then when you have a production fix, you would do it in a hotfixbranch and then merge it to both - master and release branches.

简而言之，它有 2 个主要分支（master和develop）和几种类型的支持分支（feature、release和hotfix分支）。说到您的情况，您可能会将您的发布分支部署到 QA ，然后当您进行生产修复时，您会在一个修补程序分支中进行修复，然后将其合并到主分支和发布分支。

As for your second question... well, you know, there are so many different opinions about branching strategies out there (example...) I would say, continuous production branch works great (and it doesn't mean you can't have release branches to support your workflow).

至于你的第二个问题......好吧，你知道，关于分支策略有很多不同的意见（例如......）我想说，连续生产分支效果很好（这并不意味着你不能有发布分支来支持您的工作流程）。

回答by MattJenko

At my previous job, we used a similar approach to what @Alexis mentioned, with one main difference. Keep in mind we were working on a new version of some pretty major legacy software (our codebase was several million lines of code, between Java, flex and COBOL) and had a customer partner beta testing for us. Releases were bi-/weekly, including to the customer (though they would typically be one release behind latest, as that one would go through QA first), and in that week we had to do a 'cut', test, basic QA by the client of our code, which was another developer in the company, and then release to real QA.

在我之前的工作中，我们使用了与 @Alexis 提到的类似的方法，但有一个主要区别。请记住，我们正在开发一些非常重要的遗留软件的新版本（我们的代码库有几百万行代码，介于 Java、flex 和 COBOL 之间），并且有客户合作伙伴为我们进行 beta 测试。发布是双/周发布的，包括给客户的（尽管它们通常会落后于最新的一个版本，因为那个会首先通过 QA），并且在那一周我们必须进行“剪切”、测试、基本 QA我们代码的客户，是公司的另一个开发人员，然后发布给真正的 QA。

Essentially, master was our dev branch. If a dev item was to take more than a day or two, it was completed on a feature branch and then merged into dev when ready. There was another 'future' dev branch that was reserved for fairly serious new feature work (anything that changed the program in a significant way), or major refactoring. At some point this would become main 'dev' when we decided that we had time to properly test and iron out bugs, or that it was time to introduce the new features and deal with the inevitable pain :)

本质上，master 是我们的 dev 分支。如果一个开发项目需要一两天以上的时间，它会在一个功能分支上完成，然后在准备好后合并到开发中。还有另一个“未来”开发分支，是为相当严肃的新功能工作（任何以重大方式改变程序的事情）或主要重构而保留的。在某些时候，当我们决定有时间正确测试和解决错误时，或者是时候引入新功能并处理不可避免的痛苦时，这将成为主要的“开发”:)

When it was time for a release, a new branch was created called 'release_x', then all fixes that came from QA were implemented there and merged 'up'. By that I mean that we could have two or three versions in play at any one time, so the customer would obviously have the oldest which we might do a fix for if they found a showstopper. This would be done on a hotfix branch coming off the relevant release, which at some point would be merged into that release and deleted (so you could easily see outstanding hotfixes in a branch list) and another build done and sent to the customer. The 'hotfix' branches existed so that we could pick and choose what went into a particular build, which functioned for the customer release as well as the developer release, to avoid potentially risky fixes for small issues upsetting the release of a fix for a showstopper.

当需要发布时，会创建一个名为“release_x”的新分支，然后来自 QA 的所有修复都在那里实施并合并“up”。我的意思是我们可以在任何时候有两个或三个版本在玩，所以客户显然会拥有最旧的版本，如果他们发现了阻止程序，我们可能会对其进行修复。这将在来自相关版本的修补程序分支上完成，在某些时候将合并到该版本并删除（因此您可以轻松地在分支列表中看到未完成的修补程序），并完成另一个构建并发送给客户。存在“修补程序”分支，以便我们可以选择进入特定构建的内容，这些内容既适用于客户版本，也适用于开发人员版本，

That would then be merged up to the release that the QA guys had, then that would be merged to the release the other developers were using (always the latest release due to their reliance on our plugins and j2ee infrastructure to do their work), then back into dev, just to keep everything on the level.

然后将其合并到 QA 人员所拥有的版本中，然后将其合并到其他开发人员正在使用的版本中（由于他们依赖我们的插件和 j2ee 基础设施来完成他们的工作，所以总是最新的版本），然后回到开发，只是为了让一切都保持在水平上。

All of the releases currently in play had their own automated build loop in Jenkins, as well as the dev branch, with some automated functional tests running on the more important ones (dev and QA mainly). Each build added a tag to the report on the commit that was used as HEAD, and the build number was available from the program so that we could see exactlywhich version the bug reporter was using.

当前运行的所有版本在 Jenkins 和 dev 分支中都有自己的自动构建循环，一些自动化功能测试运行在更重要的版本上（主要是 dev 和 QA）。每个构建都在提交报告中添加了一个标记，用作 HEAD，并且构建号可从程序中获得，以便我们可以准确地看到错误报告者正在使用的版本。

So essentially, two dev branches, one of them for major work to be released later as a new major version. Release branches for each release, with hotfix branches coming off those. Finding the latest release was an easy matter, look for the release branch with the biggest number.

所以本质上，有两个开发分支，其中一个用于主要工作，稍后将作为新的主要版本发布。为每个版本发布分支，修补程序分支来自这些分支。查找最新版本很容易，只需查找编号最大的发布分支即可。

The only downside was that if you did many fixes at a release several versions back, then the merging graphs were... interesting to follow :)

唯一的缺点是，如果您在多个版本的发行版中进行了许多修复，那么合并图……很有趣：)

回答by CharlesB

You should definitely

你绝对应该

• make release branches
• put in it the fixes you made after QA feedback
• merge them back to master.

• 制作发布分支
• 将您在 QA 反馈后所做的修复放入其中
• 将它们合并回主人。

That's a natural and efficient workflow.

这是一个自然而高效的工作流程。

回答by Irfan

We have used Gitflow workflowbranching model which is derived from Vincent Driessen at nvie as Alexis mentioned above.

我们使用了Gitflow 工作流分支模型，该模型源自 nvie 的 Vincent Driessen，正如上面提到的 Alexis。

The idea is that you will have two main branches Develop and Master. Developers may have their own feature branches which eventually get merged back into Develop once the feature is ready. When the development is finished on a feature, you fork a release branch off of Develop which starts your release cycle. Testing will be done on this branch and if any bugs are introduced as a result they will also be fixed on this branch but no new features will be added to this branch. Once everyone is happy with the release it gets merged into Master and tagged with a version number. You also merge it back into Develop.

这个想法是你将有两个主要分支 Develop 和 Master。开发人员可能有自己的功能分支，一旦功能准备就绪，这些分支最终会合并回 Develop。当一个功能的开发完成时，你从 Develop 中分出一个发布分支，这开始了你的发布周期。测试将在此分支上完成，如果因此引入了任何错误，它们也将在此分支上修复，但不会向此分支添加新功能。一旦每个人都对发布感到满意，它就会合并到 Master 中并标记一个版本号。您还可以将其合并回 Develop。

If a bug is found in the production code, you fork a new Hotfix branch off of Master. As soon as the fix is complete you merge Hotfix into Master. If the Hotfix was created during the release cycle you would merge it into Release otherwise into Develop.

如果在生产代码中发现错误，则从 Master 分支出一个新的 Hotfix 分支。修复完成后，您将 Hotfix 合并到 Master。如果修补程序是在发布周期中创建的，您可以将其合并到 Release 中，否则合并到 Develop 中。

without hotfix:

没有修补程序：

Feature -> Develop <=> Release -> Master

功能 -> 开发 <=> 发布 -> 大师

with hotfix during the release cycle:

在发布周期中使用修补程序：

Feature -> Develop <=> Release <- Hotfix <=> Master '

功能 -> 开发 <=> 发布 <- 修补程序 <=> 大师'

with hotfix after the release cycle:

发布周期后的修补程序：

Feature -> Develop <- Hotfix <=> Master '

功能 -> 开发 <- 修补程序 <=> 大师 '