0

我最近一直在研究 git 工作流程，哪个最适合我们的团队。

我们可以使用的最好（或最好的）git 工作流程是什么？此工作流程应尊重以下部分/大部分/所有要点：

  • 2 个团队将使用 git（每个大约 8 人），他们都在同一个应用程序上工作。每个团队可能有也可能没有自己的私有存储库。
  • 该应用程序有多个版本。版本（n+1）的开发开始可能在版本（n）发布之前开始。版本 (n+1) 上的开发不应包含在版本 (n) 中
  • 客户可能会在最后一刻决定不将 Feature x 包含在前一个月开发的下一个版本中。
  • 项目历史应该很容易理解。

我的工作流程理念：与可在此处找到的工作流程略有不同： http: //nvie.com/posts/a-successful-git-branching-model/

  • 两个团队的一个中央存储库，可通过 SSH 使用。
  • 分行主稳定。
  • 没有创建分支开发。相反，应用程序的每个版本都有自己的分支，团队在这些分支上进行开发。版本 (n+1) 的分支是从版本 (n) 的分支创建的。因此，分支 (n+1) 上可能会出现新的开发人员，而分支 (n) 上可能会出现错误修复。
  • 为每个新功能和错误修复创建一个分支，就像在模型中一样。
  • 两个团队只有一个中央存储库，因为为每个团队使用两个主要存储库似乎并不容易。每个团队有两个存储库的工作流程是什么？值得吗？
  • 大多数（如果不是全部）合并不应该快进，因为如果发生快进，似乎没有办法阻止 Feature x 被包含在内。
  • 发布时，将版本 (n) 合并到 master 中，并标记

另外，这样的策略不会有太多的分支吗？发布后很容易有大约 30~ 个错误修复。如果每个 bug 修复都建立分支，那么很快就会有很多分支。有什么办法可以避免这种情况吗？

补丁工作流程是个好主意吗？会是什么呢？我认为每个错误修复和功能都可以有自己的补丁，让客户能够选择他想要的补丁。

感谢您的帮助。

4

1 回答 1

0

Git 工作流程，例如分支。您实际上无法阻止人们拥有私有存储库和分支（尝试像这样控制它们是一个非常愚蠢的想法：您将失去分布式 VCS 的最强点）。您可以控制（仅！）的是您可以直接访问的存储库：您可以阻止其他人将他们的更改推送到其中，甚至完全关闭访问权限。在严格控制的环境中，通常不允许直接推送：更改由专门的团队成员从其他人那里拉取。经过测试，然后推动整个团队使用。

对于您要求的简单工作流程，Pro Git 书中描述的策略看起来很合适： http: //git-scm.com/book/en/Git-Branching-Branching-Workflows

请参阅git cherry-pick最后一分钟，长期完成的功能。gitk用于历史浏览（实际上有很多图形工具）。公共开发和发布分支就是这样，公共分支，可能有自己的维护者。

您可能想查看由GitHub等大型 Git 托管站点提供的工作流程。这些有类似的开源实现（如 Android 项目的 Gerrit）。

于 2012-07-26T12:37:28.617 回答