我目前在一个有多个开发人员的远程团队中工作。我们都来自不同的地方。有时或大部分时间我们处理不同的事情，有时处理相同的事情。
例如，如果我正在处理功能 A(在分支 A 上)，而我的同事正在处理功能 B(在分支 B 上)，那么开展工作的最佳实践。
- merge branchA 到 master，构建/执行测试/部署
- merge branchB 到 master，构建/执行测试/部署
或
分支出master的分支名develop，然后 merge branchA和branchB，然后构建/执行测试。
如果一切顺利，执行第 1 步和第 2 步，并将 master 部署到 prod。
我的意思是使用 develop 它是一种将来自多个分支的特性整合到单个版本中以进行 QA 的方法。
但是使用 develop 分支，你会得到一个额外的分支来维护，你基本上 merge 了相同的分支以再次掌握。
适用于贵公司/类似情况的方法有哪些？是否有针对这些情况的最佳做法？
最佳答案
使用功能分支(branchA 和 branchB)是一种很好的做法。
一般来说，生产项目应该将暂存/QA 和生产分开。无论您是在版本控制中还是在系统包中执行此操作，还是由您的项目决定。
如果您选择在 Git 中将暂存和生产分开，我建议将 master 设为开发树，将 production 设为生产树。为什么？开发人员将习惯性地 merge 到 master，所有文档都在谈论 merge 到 master，不要反对它。
生产分支不是一个大的维护问题。大多数情况下，您将进行简单的 merge 以掌握这应该是快进的，这在 Git 中非常容易且便宜。您可能希望在每次更新产品时强制 merge 记录，或者您可以使用标签。重要的是从 master 到生产的 merge 应该只由发布经理完成，而不是由随机的开发人员完成(在小商店中，开发人员也可能是发布经理)。
生产分支的另一个好处是记录热补丁。如果出现生产紧急情况并且 master 尚未准备好进行生产，您可以将热补丁直接提交到生产。然后可以将该热补丁挑选回 master 以进行适当的测试。
您可能希望拥有三个 分支。 master 用于开发，staging 用于 QA，production 用于生产。 master 被 merge 到 staging 中，假设它通过了测试，staging 被 merge 到生产中。这为 QA 提供了一个稳定的工作分支，同时生产仍然忠实地再现生产中的内容。
您也可以使用标签来实现它，有一个可以四处移动的暂存和生产标签，但这不像完整分支那样灵活。 Git 中的标签只是不会移动的分支，您会想要移动这些标签。标签的热补丁和 cherry-picking 更难，如果 master rebase 就会有问题。
基本的工作流程是...
feature_branch <---> master --QA--> staging --Release Manager--> production
请注意， merge 始终是一种方式，除了功能分支和主分支之间。
生产应急工作流程是...
staging + hot patch --Release--> production --cherry pick--> feature_branch
...然后是来自 feature_branch 的正常流程。通过首先修补暂存，您至少可以通过加速的 QA 流程运行它。热补丁可能会在下一次staging merge时产生冲突，请尽快通过开发获取合适的补丁。
关于Git 最佳实践一个或多个分支，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25190459/