对于 Web 应用程序来说，您理想的 git 分支架构是什么？
我们是一个由开发人员组成的小团队，正在构建 Web 应用程序。我们目前拥有一个实时、测试和多个开发环境。
您会建议什么分支架构，以便理想情况下每个开发人员都可以处理他的功能，这些功能可以在不影响其他开发人员/功能的情况下进行测试和部署？
目前，每个开发人员都有自己的开发分支，并重新定位到测试分支。一旦功能获得批准，开发人员就会将其更改重新设置为主版本。
只要立即测试这些功能，这种方法就有效。然而，如果一个开发人员正在开发下一个功能，而之前的功能仍在测试中，我们就需要手动处理。
感谢您的意见。
We're a small team of developers and building a web application. We're currently having a live, testing and several development environments.
What branch architecture would you suggest, so ideally each developer can work on his feature(s), these can be tested and deployed without tangenting other developers/features?
Currently, each developer has its own development branch and rebases into the testing branch. As soon as a feature is approved, the developer rebases his changes into the master.
This works as long as the features are tested immediately. However, if one developer is working on the next feature while the feature before is still tested, we need to handle things manually.
Thanks for opinions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我已经有一段时间遵循 Vincent Driessen 在他的文章 中描述的有用指南了一个成功的 Git 分支模型。
你可以看看那里，你会看到他如何描述分支管理并避免变基
It has been a while that I follow this useful guidelines described by Vincent Driessen in his article A successful Git branching model.
You can take a look there and you will see how he describes the branches management and avoid rebases
这个幻灯片（在OP和答案之后创建）在我探索时非常有帮助options，本质上建议每个开发人员从单个
develop分支分支，然后推回到那里并定期重新设置最新更改（包括警告）。This slidedeck (created after the OP and answer) was very helpful when I was exploring options, essentially recommends each developer branches from a single
developbranch, and then pushes back there and rebases regularly for latest changes (caveats included).我假设您正在使用一个集中式裸存储库，每个人都在其中推送他们的更改，然后您将最新的
testing分支拉入测试环境。为什么不使用 Git 作为实际的 DVCS，并在前一个功能的测试完成后将每个用户的功能拉入测试环境？
如果 Bill 正在开发 FeatureX，而 Ted 正在开发 FeatureY，他们可以分别在名为
testing/feature-x和testing/feature-y的分支上提供其功能，并且您可以简单地在测试环境中检查bill:testing/feature-x。如果做不到这一切，使用多个
testing/feature-name-here分支将解决传统集中式系统中的问题。只需让您的用户将他们的testing/...分支推送到中央存储库，将它们拉入测试环境，在测试后删除分支。通过检查所有前缀为testing/的分支，您始终可以看到等待测试的功能列表。如果某个功能的测试失败，您将拥有一个特定于该功能的集中分支，您可以在其中添加新的提交以在重新测试之前修复该功能。在将某个功能重新设置到唯一的测试分支后，如果某个功能测试失败，您现在该怎么办？如果其他人将他们的功能重新定位到现在包含损坏功能的分支上进行测试怎么办？
I assume you're working with a centralized bare repository where everybody is pushing their changes, and then you're pulling the latest
testingbranch into the test environment.Why not use Git as an actual DVCS and simply pull features from each user into the testing environment as the testing of the previous feature is finished?
If Bill is developing FeatureX, and Ted is developing FeatureY, they could make their features available on branches called
testing/feature-xandtesting/feature-yrespectively, and you could simply checkoutbill:testing/feature-xin the testing environment.Failing all that, using multiple
testing/feature-name-herebranches would solve your problem in a traditional centralized system. Just have your users push theirtesting/...branch to the central repo, pull them into the testing environment, remove the branch when it has been tested. You can always see a list of features waiting to be tested by examining all the branches prefixed withtesting/. If a feature's testing fails, you have a centrally located branch specific to that feature where you can add new commits to fix the feature before it is retested.What are you doing now if a feature fails testing, after rebasing the feature onto the only testing branch? What if somebody else has rebased their feature for testing onto the branch which now contains a broken feature?
对于 Web 应用程序，您（希望）每天部署工作代码，因此您可能会发现单个分支（主分支）就足够了。使用持续集成/部署，编写良好的测试，并将您的功能设计为小剂量发布而不是一次性发布。
For a web application, you're (hopefully) deploying working code daily, so you'll probably find a single branch (master) to be adequate. Use continuous integration/deployment, write good tests, and design your features to be released in small doses instead of all at once.