我正在建立我们（相对较小的）编程团队来处理源代码控制。到目前为止，一直没有控制，事情已经......随意。
该团队由6名开发人员组成，其中2名也是QA人员。 我一直在谷歌搜索这个主题，这是压倒性的！ 到目前为止，我做出的唯一决定是我们将使用mercurial。
背景：这是一个用PHP开发的Web应用程序。新功能的不断发展（这意味着同样不断修复错误:-P） 我们首先将所有Web开发外包，这意味着我们的生产代码由另一家公司托管。因此我们可以使用Mercurial在我们的内部网络中进行开发和测试，但是当它准备好上线时，我们需要将文件ftp转移到yonder公司。 （愚蠢？这是它的方式......他们也为我们做seo和其他工作，所以管理层不打算与他们分开。）
以下是工作流程的要求：
我对此进行设置的想法是......
因此，程序员希望开始研究新功能。他创造了一个辫子，做他的工作，他很高兴，与他的主要分支合并。现在他从开发中获取更改，合并，推送到dev。
质量保证人员将从开发人员转到QA回购。由于许多人可以推动开发，并且我们希望一次专注于测试一个新功能，MrQA可以选择应用哪些变更集（或者无论术语是什么）。测试功能 - 工作！ ftp到生产。然后可以开始测试dev的下一个功能。对于错误 - 程序员将在其本地存储库中进行修复，直接发送到QA，然后从QA进行修复。
但是......如果我们有两个QA人员在QA回购中同时进行测试（测试两个新功能）怎么办？ ftp传输将发送所有文件...这意味着所有功能都需要准备好，我们需要等待它们都完成。这是我们当前问题的一部分，在我自己的修复工作开始之前等待其他开发人员测试的东西...这就是为什么我们想要源代码控制...所以现在我很困惑！
好的，现在我需要一些建议。我读到每个版本都有单独的分支。每个发布版本的单独分支。我真的不知道该怎么想......上面描述的工作流程是否可用？这对我们的小团队来说是否有点过分？或者，它太简单了吗？因为我是那个在版本控制方面销售所有人的人，所以我不想设置一些在一周后会失败的东西......
提前感谢您前来救援!!
答案 0 :(得分：4)
首先祝贺做出某种版本控制的决定。早期可能会有一些痛苦，但从长远来看它是值得的。
我最初的想法是，开发方面的事情听起来不错。我不相信需要一台中央服务器，但许多人毫无问题地使用它。
我认为问题开始在QA周围蔓延。你说：
质量保证人员将从开发人员转到QA回购。由于许多人可以推动开发，我们希望一次专注于测试一个新功能，MrQA可以选择应用哪些变更集
这意味着QA人从开发树中挑选，因此我假设他正在使用像graft这样的东西。在这种情况下，QA有一个在dev生态系统中不存在的分支。当开发人员需要修复错误时，他会在开发树中修复它，还是在QA分支之外修复它？如果他在QA分支上修复它（那就是bug的位置）它是如何回到dev的？我可以在这里看到dev和QA永远分歧的问题。
我个人建议阅读how the mercurial project does it。基本上，QA将测试的每个版本都有一个命名分支。 QA的任何错误修正都会在该分支上进行，并且可以合并回开发分支。作为正常流程的一部分，没有采摘樱桃，因为我认为从长远来看会很难管理。
还有其他的工作流程（可能和人们使用mercurial一样多;-)），但这是一个很好的起点，你可以根据需要进行调整。
答案 1 :(得分：2)
如果我们同时在QA回购中测试两个QA人员（测试两个新功能）怎么办？
每个人都有自己的回购（它们可能是相同的，但QA测试用于不同的分支）。也许这里将是中央QA-repo的地方，其中只有QA可以提交通过所有测试变更集和后提交挂钩发布每次更改到外部第三方
我读到每个修订版都有单独的分支。每个发布版本的单独分支
我希望，这是“每个功能|分支每个bugfix |分支每个市长 - 次要版本”，而不是每个变更集分支
上述工作流程是否可用？
是的，它可能会让现实生活中出现一些改变，但这是一个自然的过程
我们的小团队是否有点过分了？
我不这么认为 - 这是合乎逻辑的，半透明的（QA部分似乎只是在某种程度上得到了改进）并且可以扩展到广泛的团队（而“混乱的无政府状态”通信可能被替换通过一些更多的分层模型）
太简单了吗？
在这里看不到过于简单