git工作流程有3个分支建议

Question

我正在开展一个项目，我们正试图以最有效的方式（对我们来说）使用git，并决定为2个子团队创建2个分支，以便进行工作。主分支。

有时我们会提交到master，如果它是泛型的，应该进入两个分支，然后我们想要在其他两个分支中进行这些更改。

1. 这应该是合并还是重组到其他2个分支？

2. 这是一个疯狂的工作流程吗？如果是的话，请提出建议！

Answer 1

我没有看到为两支球队创建两个分支的重点。工作应根据其性质分开，而不是由谁来处理。

这就是我的建议：

• 使用功能分支：除了微小的提交（例如拼写错误等）外，您的大部分工作都应该在这些主题分支上。 如果您有功能，错误修复或应该处理的故障单：创建分支 feat-something ，并在那里工作。
• 使用 dev 或 release-X （其中 X 是版本号）分支：当功能的分支工作已完成，测试并正常工作，将其重新绑定到 dev 。
• 永远不要提交 master ，这个分支只能由首席开发人员CTO重新设置。当您认为需要时，将 dev 的工作重新设置为 master 。

这（基本上）是我们如何处理一个非常大的项目。如果项目不大，您可以在没有 dev 分支的情况下工作。

查看这篇着名的文章，该文章展示了一个做得很好的工作流程：A successful Git branching model。

Answer 2

这取决于这些是否是分享一些常见内容的2个独立项目;如果是这样，那么创建一个单独的库并使用子模块 - 而不是将所有内容填充到一个仓库中。

否则我会建议反对所描述的方法。它可能会达到这两个分支如此分歧以至于合并它们几乎不可能的程度。由于git是一个分布式系统，所以在主服务器上进行所有主要开发，因此每个实现的功能都会根据需要创建分支并经常合并。使用标记来标记重要的开发里程碑。

Answer 3

倒车：

2）不，这不是一个疯狂的工作流程。您的子团队成员可能拥有自己的存储库和分支。当子团队拥有稳定的产品时，他们会将其推送到主存储库中的分支。然后，集成主管将获取主存储库中子团队分支上的内容，并在适当时合并/重新绑定到主服务器（正如您所说的要共享的内容）。

1）因此假设子团队A和B都在Tag-M1处从主站分支出来，而子团队A的工作现在又回到了Tag-M2的主站。同时子团队B已经转移到Tag-B2。你应该改变或合并到分支B上。我想你想避免使用Tag-M2来重新分支-B。你的子团队B成员正从分支B中撤出;当你改变时，你将改变分支-B上的历史，这将使子团B的拉动变得复杂。

请注意，从主存储库更新时，您的子团队可能更喜欢'git pull --rebase'。