具有功能分支和功能的Git工作流程团队合作

Question

我最近一直在寻找git工作流程，哪一个对我们的团队来说是最好的。

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

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

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

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

另外，由于这个策略会不会有太多的分支？在发布后很容易就会有大约30个bug修复。如果为每个错误修复分支，那么很快就会有很多分支。有什么办法可以避免吗？

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

感谢您的帮助。

Answer 1

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

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

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

您可能希望了解由大型Git托管网站（如 GitHub ）推动的工作流程。有类似的开源实现（如Android项目的Gerrit）。