Git工作流及其功能分支&；团队合作

我最近一直在研究git工作流，以及哪种工作流对我们的团队最合适

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

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

我的工作流程想法：与此处所示的工作流程略有不同：

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

此外，这种策略会不会导致太多分支？发布后，很容易会有大约30个bug修复。如果每个bug修复都有分支，那么很快就会有很多分支。有什么办法可以避免吗

补丁工作流是个好主意吗？可能是什么？我认为每一个bug修复和特性都可以有自己的补丁，让客户能够选择他想要的补丁

---

感谢您的帮助。

Git工作流，如分支。实际上，你无法阻止人们拥有私人回购和分支机构（试图这样控制它们是一个非常愚蠢的想法：你将失去分布式风险投资的优势）。您可以控制（仅！）的是您可以直接访问的存储库：您可以阻止其他人将其更改推入存储库，甚至完全关闭访问。在严格控制的环境中，通常不允许直接推送：更改是由专门的团队成员从其他团队中拉出来的。经过测试，并在随后推动在整个团队范围内使用

对于您请求的简单工作流，Pro Git book中描述的策略看起来很合适：

有关最后一分钟完成已久的功能，请参见

git cherry pick

gitk

用于历史浏览（实际上有很多图形工具用于此）。公共开发和发布分支只是公共分支，可能有自己的维护者

---

您可能想看看大型Git托管站点（如GitHub）所促进的工作流。有类似的开源实现（比如Android项目的Gerrit）。

实际上，我的意思是每个人都有自己的本地存储库，两个团队都有一个中央远程存储库，或者每个团队有两个远程存储库，或者有两个以上的原因，我现在想不起来。你是说只有一个人X先生能够推送到远程存储库，他从另外两个团队那里获取所有信息？然后，团队成员将从远程存储库或X先生那里提取？只有一个人（集成商），是的。“远程存储库”不是我会用的词。它是“公共存储库”。每个人都从那里停车。是的，收集变化是他的任务。事实上，这更像是：每个人都在烦他拉车。谷歌的“拉请求暴躁的Linux内核维护者”：）我有点担心，它不会为集成者增加太多任务吗？如果我们遵循分支策略，15个人总是创建新的分支，我认为这可能会给他带来很多工作，如果有冲突，甚至更多。我们计划使用ssh存储库，并与Eclipse（EGit）合作。我们没有考虑GITHUB，因为我们已经有服务器了。它会增加ssh存储库所不具备的功能吗？您认为Linux内核开发是如何工作的？他们当然有更多的15人，他们都在同一个代码库上同时工作。我没有说：使用Github。我说：看看它促进的工作流程。是的，类似Github的软件将通过简化这些工作流来增加功能。