git - Git 中的分支和 merge 最佳实践

Question

我们有一个 4 人的开发团队，最近搬到了 Git。我们想学习有关分支和 merge 工作流的最佳实践。

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

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

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

我有以下问题:

1. 我们应该从 dev 还是从 master 分支功能分支？
2. 当一个特性分支就绪后，我们应该将特性分支 merge 到开发中，然后将开发 merge 到暂存中，还是将特性分支 merge 到暂存中，然后将特性分支 merge 到主分支中？

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

你有什么看法？最佳做法是什么？

Answer 1

虽然 Git Flow 是一个出色的分支模型，但您提出的问题是一个更大问题的征兆:Git Flow 对于从事消费网络产品的小团队来说太重了(我假设您正在工作在消费者网络产品上，如果您正在编写核电站控制室代码，请随时忽略)。

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

现在安装 CD 非常容易:

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

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

我鼓励你尝试。它将解放您的思想，专注于真正重要的事情:打造出色的产品!不信你看看这个excellent presentation from Github .