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

Question

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

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

• 分期是从硕士分支
• dev从分期开始分支

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

我有以下问题:

1. 我们应该从dev或master分支功能分支吗？
2. 当功能分支准备就绪时,我们是否应该将功能分支合并到dev中,然后将dev合并到staging中,或者将功能分支合并到staging中,然后将功能分支合并到master中？

我认为我们应该从master分支并合并功能分支,因为dev中可能存在一些我们可能不希望合并到staging和master的东西.

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

Answer 1

这总取决于您希望如何工作以及团队协议.那就是说.

1. 功能从dev分支开始进入其自己的分支.从主分支,您应该只分支修补程序,因为主分支应始终是您的软件的稳定版本.
2. 当一个功能分支完成后,它应该合并到dev中,然后在某些时候你应该将你的下一个版本从dev(包括一些功能)分支到一个新的'release/*'分支,一旦它稳定下来,它将被合并到master中并经过充分测试.

在Atlassian页面中,您可以对此工作流程进行非常好的解释

这种工作流程的整个想法是拥有一个稳定的版本分支,在这个分支中你可以立即工作并修复任何bug,如果你需要足够的信心它仍然是稳定的,没有新的功能或重构将在没有注意到的情况下滑入.

还要为每个新功能提供隔离和自由,这些功能将在其自己的分支中开发,而不会产生其他功能的噪音.最后,您将把您的功能合并到您的dev分支中,然后从那里合并到下一个版本的主分支中.

我唯一要建议的是学习如何在每次将另一个功能合并到dev中时在dev分支上重新设置功能分支,以避免在合并时解决冲突,但是在功能分支上单独知道你知道什么你的改变是.

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

Answer 2

虽然Git Flow是一个优秀的分支模型,但您提出的问题是一个更大问题的症状:Git Flow对于处理消费者Web产品的小团队来说太沉重了(我假设您正在处理消费者网络产品,如果您正在编码核电站控制室,请随意忽略).

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

现在很容易设置CD:

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

对它有很多共同的反对意见,所有这些都可以概括为"但如果我介绍一个错误会怎样？!".答案是"你会解决它!".如果您编写测试,如果您监视生产站点,如果您进行代码审查,如果您进行结对编程,如果您使用功能标记,并且如果您保持小功能,那么您从CD获得的好处将超过偶尔的问题任何一天.

我鼓励你试试.它会释放你的思想,专注于真正重要的事情:构建一个伟大的产品!如果您不相信我,请看看Github的精彩演示.

Answer 3

我们确定了一个名为Git Flow的工作流程,但是我们不是从dev分支功能,而是从当前版本中分支它们.这使我们能够以不同的速度处理单独的问题.如果他们在质量保证方面取得成功,他们会进入发布阶段.

关于分支和部署:

• 该开发分支自动部署到测试服务器.
• 当前版本分支自动部署到登台服务器.
• 该主分支手动部署通过释放主住服务器.

工作流程如下:

1. 在每个版本/ sprint的开头创建一个来自master的发布分支,例如release/2015-may.
2. 从2015年5月发布创建开发分支
3. 处理新功能,从发布分支并将其命名为feature/ISSUE_NUMBER.
4. 处理您的功能.
5. 当它准备好进行测试时,将其合并到dev中.
6. 如果已被接受,请将其合并到当前版本分支中.
7. 如果未被接受,请转到步骤4.
8. 发布准备就绪后,将其合并到master中

在部署了发布版本并发现了一个关键错误后,我们从master(例如hotfix/ISSUE_NUMBER)分支一个修补程序分支,将其合并回master并再次部署.