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 回答