1

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

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

  1. 那应该是合并还是变基到其他两个分支？

  2. 这是一个疯狂的工作流程吗？如果有，请给点建议！

4

3 回答 3

4

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

这就是我的建议：

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

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

查看这篇著名的文章，它展示了一个非常出色的工作流程：一个成功的 Git 分支模型。

于 2012-05-15T12:13:17.323 回答
1

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

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

于 2012-05-15T10:06:47.213 回答
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”。

于 2012-05-16T02:35:05.870 回答