9

首先，对不起，如果这是重复的，但我尝试搜索，我能找到的只是关于如何在 Git 中创建分支的东西等等。这不是我想要的。我试图弄清楚不同的人如何设置他们的 Git 分支以匹配他们的工作流程。

让我举个例子说明我们公司是如何做到的：

  1. 开发人员在本地提交到他们自己的分支
  2. 开发人员将提交推送到他们的远程，一个持续构建系统检查它，另一个开发人员审查它
  3. 如果审查/构建通过，提交将合并到一个 QA 分支（如果失败，则进行更多提交，直到审查/构建通过）
  4. 如果提交未通过 QA，则会进行还原提交以将其取出
  5. 在准备好足够的 QA 提交后，我们的主分支获取提交（QA 分支基于它，因此不需要合并）
  6. 定期从主分支中获取分支，并用于“在野外”释放。如果这里发现问题，会再次使用revert commit来移除代码
  7. 发布后，开发人员将他们的分支重新定位到主分支（获取他们以前的提交和其他开发人员的提交）

现在，这个系统存在一些问题；我会在评论中指出一些，但我并不是真的在寻找“请为我修复我们的系统”，我只是想看看我们可以使用哪些其他分支选项，这样我就可以权衡各种可能性。

所以，如果你曾在多家使用 Git 的公司工作过（或者更好的是，如果你是某种顾问，见过大量的 Git 设置），你能否分享一下：不同公司如何设置 Git 分支（并移动提交它们之间）以促进发展的各个阶段......同时尽量减少烦人？我确信一定有一些常见的模式......但我不知道它们是什么。

PS 如果你只看过一个 Git 设置，但你认为它很有趣，请务必发布它。但是，我想将答案授予提供可能选项的最佳细分的人，并且我希望这将来自看过多个 Git 设置的人。

4

3 回答 3

6

我现在管理着几个使用 Git 的团队，我们已经制定了一种非常适合我们的策略。

  • Master 始终是生产中产品的副本。当代码发布时，当前分支会快速转发到 master，并添加一个标签，以便及时标记发布，如果需要，我们可以获取代码。
  • 开发人员可以自由地在他们的分支范围内按照自己喜欢的方式工作，但是对于功能分支，我们通常为每个功能设置一个分支，并且多个开发人员合并到该分支并从该分支合并以共享该功能的工作。
  • 在发布候选版本时，会创建一个 RC_XXX 分支，并将足够远的功能分支全部合并到其中。然后对其进行测试，并从中分支出错误修复。
  • 当一切都说完了，RC_XXX 分支被发布到生产环境中，在它“坚持”几天后，我们将它提升为 master，然后新的特性分支基于它。

这非常有效，因为只需从 master 分支就可以轻松创建和部署针对生产的热修复，并且开发人员可以在必要时针对功能分支进行分支以引入依赖项。

于 2010-10-11T13:30:17.003 回答
1

这个怎么样（我忽略了开发人员在他们的机器上拥有的东西）：

  • 每个开发人员都有一个接受的补丁分支（此处为 QA 提交），它基于最后一个主检查点（每个版本的新分支）
  • 每个开发人员都有一个他提交的待处理补丁分支，该分支会不断地根据已接受的补丁分支（持久分支）重新建立基础
  • 一旦对所有开发人员进行了 QA，所有接受的补丁分支都将合并到 master
  • 创建新的 QA 分支，所有开发人员再次变基
于 2010-10-09T19:15:45.067 回答
0

“发布后，开发人员重新定位他们的分支”：哎哟......

我（目前）还不是 Git 顾问，但根据经验，开发人员应该更频繁地重新调整他们的工作（而不是仅仅“在发布之后”）。
否则，就像您在评论中提到的那样，这会导致很多“ git revert”（这有效，但应该仍然是例外情况而不是常见修复）。

点对点协作是可能的，但需要一些纪律，因为它需要建立一个裸仓库和本地协议。

于 2010-10-09T19:17:43.423 回答