我们是一个由开发人员组成的小团队并构建一个Web应用程序。我们目前正在进行实时测试和多个开发环境。
您建议使用哪种分支架构，理想情况下，每个开发人员都可以使用他的功能，这些可以在不与其他开发人员/功能相切的情况下进行测试和部署？
目前，每个开发人员都有自己的开发分支并重新进入测试分支。一旦某项功能获得批准，开发人员就会将其更改重新加入主数据中。
只要立即测试功能，这就有效。但是，如果一个开发人员正在处理下一个功能，而之前的功能仍在测试中，我们需要手动处理。
感谢您的意见。
答案 0 :(得分：3)
我已经有一段时间遵循Vincent Driessen在他的文章A successful Git branching model中描述的有用指南。
你可以看看那里，你会看到他如何描述分支机构管理并避免重组
答案 1 :(得分：0)
我假设您正在使用集中式裸存储库，每个人都在推动他们的更改，然后您将最新的testing分支拉入测试环境。
为什么不将Git用作实际的DVCS，只需将每个用户的功能拉入测试环境，因为上一个功能的测试已经完成？
如果Bill正在开发FeatureX，并且Ted正在开发FeatureY，他们可以分别在名为testing/feature-x和testing/feature-y的分支上提供其功能，您只需在测试中签出bill:testing/feature-x即可环境。
如果不这样做，使用多个testing/feature-name-here分支可以解决传统集中式系统中的问题。只需让您的用户将他们的testing/...分支推送到中央仓库，将其拉入测试环境，在测试时删除分支。通过检查前缀为testing/的所有分支，您始终可以看到等待测试的功能列表。如果某项功能的测试失败，您将拥有一个专门针对该功能的中心分支，您可以在重新测试该功能之前添加新提交以修复该功能。
在将功能重新定位到唯一的测试分支后，如果功能测试失败，您现在在做什么？如果其他人已经将他们的功能重新定位到现在包含破损功能的分支上，该怎么办？
答案 2 :(得分：0)
对于Web应用程序，您（希望）每天部署工作代码，因此您可能会发现单个分支（主服务器）足够。使用持续集成/部署，编写好的测试，并设计您的功能，以小剂量而不是一次性发布。
答案 3 :(得分：0)
This slidedeck（在OP和答案之后创建）在我探索选项时非常有用，基本上从单个develop分支推荐每个开发人员分支，然后推回那里并定期重新定位以获取最新信息变化（包括警告）。