在 Git 中分支和合并最佳实践

Branching and merging best practices in Git

提问by Gaui

We have a developer team of 4 and have recently moved to Git. We want to learn best practices regarding workflow with branching and merging.

我们有一个 4 人的开发团队，最近已经转移到 Git。我们希望通过分支和合并学习有关工作流的最佳实践。

We are using a lightweight version of Git Flow. We have a dev, staging and a master branch which are all linear with each other.

我们正在使用 Git Flow 的轻量级版本。我们有一个 dev、staging 和一个 master 分支，它们都是线性的。

• staging is branched from master
• dev is branched from staging

• staging 从 master 分支出来
• dev 是从 staging 分支出来的

On top of that we use feature and hotfix branches to work on new features and fix bugs.

最重要的是，我们使用功能和修补程序分支来处理新功能和修复错误。

I have the following questions:

我有以下问题：

1. Should we branch feature branches from dev or from master?
2. When a feature branch is ready, should we merge the feature branch into dev, then merge dev into staging, or merge the feature branch into staging and then the feature branch into master?

1. 我们应该从 dev 还是从 master 分支功能分支？
2. 当一个功能分支准备好时，我们应该先将功能分支合并到 dev，然后将 dev 合并到 staging，还是先将功能分支合并到 staging，然后将功能分支合并到 master？

I think we should branch from master and merge the feature branch up, because there might be something in dev that we might not want to merge to staging and master.

我认为我们应该从 master 分支并合并 feature 分支，因为 dev 中可能有一些我们可能不想合并到 staging 和 master 的东西。

What is your opinion? What are the best practices?

你有什么意见？最佳做法是什么？

采纳答案by Gaui

We settled on a workflow called Git Flow, but instead of branching features from dev, we branch them from the current release. This makes us able to work on seperate issues in different speeds. If they are successful in QA, they go into the release.

我们确定了一个名为Git Flow的工作流，但我们不是从 dev 分支功能，而是从当前版本分支它们。这使我们能够以不同的速度处理不同的问题。如果他们在 QA 中成功，他们就会进入发布阶段。

Regarding branches and deployment:

关于分支和部署：

• The devbranch is deployed automatically to test servers.
• The current release branch is deployed automatically to staging servers.
• The masterbranch is deployed manually to live servers by the release-master.

• 该开发分支自动部署到测试服务器。
• 当前发布分支会自动部署到登台服务器。
• 该主分支手动部署到释放主Live服务器。

The workflow is the following:

工作流程如下：

1. Create a release branch from masterin the beginning of each release/sprint, e.g. release/2015-may.
2. Create a devbranch from release/2015-may
3. Working on a new feature, branch from release and name it feature/ISSUE_NUMBER.
4. Work on your feature.
5. When it's ready for testing, merge it into dev.
6. If it's accepted, merge it into the current release branch.
7. If it's not accepted, go to step 4.
8. When the release is ready, merge it into master

1. 在每个发布/冲刺开始时从master创建一个发布分支，例如release/2015-may。
2. 从release/2015-may创建一个dev分支
3. 处理一个新功能，从发布分支并将其命名为 feature/ ISSUE_NUMBER。
4. 处理您的功能。
5. 当它准备好进行测试时，将其合并到 dev 中。
6. 如果它被接受，则将其合并到当前发布分支中。
7. 如果不接受，请转到步骤 4。
8. 当发布准备好时，将其合并到master

After the release has been deployed to live and a critical bug is discovered, we branch a hotfix branch from master (e.g. hotfix/ISSUE_NUMBER), merge it back into master and deploy again.

在发布版本部署上线并发现一个关键错误后，我们从 master 分支出一个 hotfix 分支（例如 hotfix/ ISSUE_NUMBER），将其合并回 master 并再次部署。

回答by Pablo Carranza

This always depends on how do you want to work and the team agreement. That said.

这始终取决于您想如何工作以及团队协议。那说。

1. A feature starts from the dev branch into its own branch. From the master branch you should only branch hotfixesbecause the master branch should always be the stableversion of your software.
2. When a feature branchis done, it should be merged into dev, then at some point you should branch your next release from dev (including some features) into a new 'release/*' branchwhich will be merged into master once it is stabilized and well tested.

1. 一个特性从 dev 分支开始进入它自己的分支。从 master 分支你应该只分支修补程序，因为master 分支应该始终是你软件的稳定版本。
2. 当一个特性分支完成后，它应该被合并到 dev，然后在某个时候你应该将你的下一个版本从 dev（包括一些特性）分支到一个新的'release/*'分支，一旦它稳定下来就会合并到 master并经过良好测试。

In the Atlassian page you have a very nice explanation of this workflow

在Atlassian 页面中，您对此工作流程有很好的解释

The whole idea with this kind of workflows is to have a stable version branch in which you can work and fix any bug immediately if you need to with enough confidence that it will still be stable and no new feature or refactorization will slip in without noticing.

这种工作流的整个想法是拥有一个稳定版本的分支，如果您需要有足够的信心确保它仍然是稳定的并且没有新功能或重构会在没有注意到的情况下出现，您可以在其中立即工作并修复任何错误。

Also to have isolation and freedom for each new feature which will be developed in its own branch with no noise from other features. Then finally you will merge your features into your dev branch and from there into the master branch for the next release.

还为每个将在其自己的分支中开发的新功能提供隔离和自由，而不会受到其他功能的干扰。然后最后你将你的特性合并到你的 dev 分支，然后从那里合并到下一个版本的 master 分支。

The only thing I would recommend for you is to learn how to rebase your feature branches on top of the dev branch each time another feature is merged into dev to avoid resolving conflicts on merge time, but in isolation on the feature branch where you know what your changes are.

我唯一推荐给你的是学习如何在每次将另一个功能合并到 dev 时将你的功能分支重新设置在 dev 分支之上，以避免在合并时解决冲突，但在你知道什么的功能分支上隔离你的变化是。

It also looks like this question was asked before

看起来这个问题之前也有人问过

回答by quarterdome

While Git Flow is an excellent branching model, the questions you are asking are a symptom of a bigger problem: Git Flow is too heavy for a small team working on a consumer web product (I am making an assumption that you are working on consumer web product, feel free to ignore if you are coding nuclear power plant control room).

虽然 Git Flow 是一个出色的分支模型，但您提出的问题是一个更大问题的征兆：Git Flow 对于从事消费类 Web 产品的小团队来说太重了（我假设您正在从事消费类 Web产品，如果您正在编码核电站控制室，请随意忽略）。

I would like to encourage you to consider Continuous Deployment (CD) with an extremely simple branching model:

我想鼓励您考虑使用极其简单的分支模型进行持续部署 (CD)：

It is very easy to setup CD nowadays:

现在设置 CD 非常容易：

1. Use Travis, CodeShip, Jenkins or similar system to run a full build and test suite on every commit pushed on every branch of your codebase
2. Setup Travis/Codeship/Jenkins to deploy to production every commit to master that passes the tests.
3. Create a new branch from masterfor every new feature.
4. Code a new feature and test it on a branch.
5. Merge a feature branch into master, and watch it go live.

1. 使用Travis、CodeShip、 Jenkins 或类似系统在代码库的每个分支上推送的每个提交上运行完整的构建和测试套件
2. 设置 Travis/Codeship/Jenkins 以将每个通过测试的 master 提交部署到生产中。
3. master为每个新功能创建一个新分支。
4. 编写新功能并在分支上进行测试。
5. 将功能分支合并到 中master，并观看它上线。

There are a lot of common objections to it, that all can be summarized as "but what if I introduce a bug?!". The answer is "You'll fix it!". If you write tests, if you monitor your production site, if you do code reviews, if you practice pair programming, if you use feature flags, and if you keep your features small, then the benefits you get from CD will outweigh the occasional problems any day.

对此有很多共同的反对意见，所有这些都可以概括为“但是如果我引入了一个错误怎么办？！”。答案是“你会解决它！”。如果你编写测试，如果你监控你的生产站点，如果你做代码，如果你练习结对编程，如果你使用功能标志，如果你保持你的功能小，那么你从 CD 中获得的好处将超过偶尔出现的问题任何一天。

I encourage you to try. It will free your mind to focus on what truly matters: building a great product! If you do not believe me, take a look at this excellent presentation from Github.

我鼓励你尝试。它将解放您的注意力，让您专注于真正重要的事情：打造出色的产品！如果您不相信我，请看一看Github 上的精彩演示。