带有 3 个分支建议的 git 工作流答案

【问题标题】：git workflow with 3 branches advice带有 3 个分支建议的 git 工作流
【发布时间】：2012-05-22 19:39:04
【问题描述】：

我正在做一个项目，我们试图以最有效的方式（对我们而言）掌握使用 git，并决定创建 2 个分支供 2 个子团队工作，与主分支。

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

应该合并还是变基到其他 2 个分支？
这是一个疯狂的工作流程吗？如果有，请提出建议！

【问题讨论】：

标签： git version-control git-branch branching-and-merging

【解决方案1】：

倒车：

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

1) 因此假设子团队 A 和 B 都从 Tag-M1 的 master 分支，并且子团队 A 的工作现在又回到 Tag-M2 的 master 上。与此同时，小队 B 已移至 Tag-B2。你应该变基还是合并到分支-B。我认为您想避免从 Tag-M2 中重新设置分支 B。您的子团队 B 成员正在从分支 B 拉出；当您变基时，您将更改分支 B 上的历史记录，这将使子团队 B 的拉取复杂化。

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

【讨论】：

【解决方案2】：

我看不出为两个团队创建两个分支的意义。工作应该根据其性质来分开，而不是根据谁来工作。

这是我的建议：

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

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

查看这篇著名的文章，该文章展示了一个非常出色的工作流程：A successful Git branching model。

【讨论】：

对不起，分支确实是特征分支。碰巧每个人都映射到一个子团队。你的工作流程听起来很有趣，是的，我看过那篇博文。感谢您的建议:-)。

【解决方案3】：

这取决于这两个独立的项目是否共享一些共同的东西；如果是这样，那么创建一个单独的库并使用子模块 - 而不是将所有东西都塞进一个仓库中。

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

【讨论】：

这不是 2 个独立的项目。是的，这就是我担心将 2 个分支最终合并到 master 时会发生的事情。但是如果你想让 master 成为一个稳定的分支，而另外两个正在实现特定的大型新部分呢？
master 是开发分支；这是所有新的时髦的东西（稳定！）上架的地方。当您想要稳定时 - 然后您为此目的创建分支（并在之前标记转移点）。为什么？因为稳定意味着没有新功能 - 只是修复。而且这些分支通常与分支点相差不大。关闭 master 在开发期间创建每个功能分支，并在返回 master 时将它们合并。