在Git中分支和合并最佳实践 [英] Branching and merging best practices in Git

问题描述

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

我们使用的是Git Flow的轻量级版本。我们有一个开发者，分期和主分支，它们都是线性的。

• 临时分支从主分支
  
• dev从分期分支

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

我有以下问题：

1. 我们是否应该从dev或来自主？


2. 当功能分支准备就绪时，我们应该将功能分支合并到dev中，然后将dev合并到分段中，或者将功能分支合并到分段中，然后将功能分支合并到主功能中？ li>
   

我认为我们应该从master分支并合并功能分支，因为dev中可能有某些东西可能不想合并到分期和主人。

您的意见是什么？什么是最佳实践？

解决方案

我们在一个名为 Git Flow ，但是我们不是从dev分支功能，而是从当前版本分支它们。这使我们能够以不同的速度处理单独的问题。如果他们在QA中获得成功，他们将进入发布版。

关于分支机构和部署：

• dev 分支自动部署到测试服务器。


• 当前版本分支自动部署到登台服务器。 $ b master 分支由发布主服务器手动部署到活服务器。

工作流程如下：

1. 在每个发行版/ sprint的开头，从 master 创建发行版分支，例如 release / 2015-may 。


2. 从 release / 2015-may 创建 li>
   
3. 使用新功能，从发行版分支并命名为功能/ ISSUE_NUMBER 。


4. 工作
   
5. 准备好进行测试时，将其合并到开发包中。


6. 如果接受，则将其合并到当前发行版分支中。 / li>
   
7. 如果未接受，请转至第4步。 当发布准备就绪后，将其合并到 master

在发布部署到现场并发现一个严重错误后，我们从master分支一个修补程序分支（例如hotfix / ISSUE_NUMBER ），将它合并回主并再次部署。

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.

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.

• staging is branched from master
• dev is branched from 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?

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.

What is your opinion? What are the best practices?

解决方案

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.

Regarding branches and deployment:

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

The workflow is the following:

1. Create a release branch from master in the beginning of each release/sprint, e.g. release/2015-may .
2. Create a dev branch 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

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.

这篇关于在Git中分支和合并最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！