我目前在一个有多个开发人员的远程团队工作。我们来自不同的地方。有时或大部分时间我们处理不同的事情，有时候是在相同的事情上。
例如，如果我正在处理功能A（在branchA上）并且我的同事正在处理功能B（在branchB上），那么提交的最佳做法是什么？我们的工作。
或
对develop的分支名称master进行分支，然后将branchA和branchB合并到其上，然后构建/执行测试。
如果一切顺利，请执行步骤1和2并将主服务器部署到prod。
我的意思是使用develop这是一种将多个分支的功能转换为QA的单个版本的方法。
但是使用开发分支，你需要另外一个分支来维护，你基本上将相同的分支合并到master。
对您的公司/类似情况有哪些方法？是否有关于这些情况的最佳做法？
答案 0 :(得分：2)
使用特征分支（branchA和branchB）是一种很好的做法。
通常，生产项目应该在分期/质量保证和生产之间进行分离。无论是在版本控制中还是在系统包中执行此操作，或者您的项目都需要执行此操作。
如果您选择在Git中将分段与生产分开，我建议您掌握开发树并生成生产树。为什么？开发人员习惯性地合并为主人，所有的文档都谈论合并掌握，不要与之斗争。
生产分支不是一个大的维护问题。大多数情况下，你会做一些简单的合并来掌握它应该是快进的，这在Git中非常简单和便宜。您可能希望每次更新生产时强制合并记录，或者您可以使用标记。重要的是从主人到生产的合并应该只由发布经理完成，而不是由随机开发人员（在小商店中，开发人员也可能是发布经理）。
生产分支的另一个好处是记录热补丁。如果存在生产紧急情况且主服务器尚未准备好生产，您可以直接将热补丁提交给生产。然后可以将该热补丁挑回主人进行正确的测试。
您可能希望拥有三个分支。开发硕士，QA升级和生产生产。 master被合并到staging中，并且假设它通过了测试，staging将合并到生产中。这使QA成为一个稳定的分支，而生产仍然忠实地再现生产中的东西。
您还可以使用标记实现此功能，具有可移动的分段和生产标记，但这不像完整分支那样灵活。 Git中的标签只是不移动的分支，您需要移动这些标签。使用标签进行热补丁和采摘樱桃会更难，如果掌握了rebase，就会出现问题。
基本工作流程是......
feature_branch <---> master --QA--> staging --Release Manager--> production
请注意，合并始终是一种方式，除了功能分支和主控之间。
生产应急工作流程......
staging + hot patch --Release--> production --cherry pick--> feature_branch
...然后从feature_branch正常流动。通过先修补分段，您至少可以通过快速的QA流程来运行它。热补丁可能会在下一个分段合并中引起冲突，因此请尽快通过开发获得适当的补丁。
答案 1 :(得分：0)
如果你想表示一个已经准备好接受QA的版本，那么在git中这样做的惯用方法就是使用tag。而其他SCM工具（如ClearCase或Accurev）使用层次结构来表示开发/测试/发布的阶段，我从来没有在我的任何项目或团队中需要这个，我也没有预见到它。 git分支的主要目的是实现并行性。如果不同的开发工作之间存在唯一的并行性，那么您的branchA和branchB分支就足够了。
答案 2 :(得分：0)
所有这些做法最终都指向一个目标 - 在生产中部署代码，或者更一般地说，尽快发布产品版本。您几乎总是不想弄乱用于部署生产的master分支。一个干净且经QA批准的功能分支就是要合并到master中的所有功能，除非你正在进行一些基本的重构。
使用单独的develop分支，您不会有开发人员为了在prod master上进行测试而进行不必要的提交的风险。在大多数情况下，开发人员创建的功能分支需要有一组提交仅用于测试。在prod master分支中更改标志或仅为调试添加日志没有意义吗？您只需将提交转储到develop分支上，然后继续进行测试。但是在prod master分支中保留一个更清晰的历史记录，只进行编码逻辑的提交。如果您希望在部署代码后跟踪特定功能及其开发工作流程，那么您将在prod master中查看更简洁，更少的有意义的提交。它变得简单易行，使您的团队能够将更少的时间用于解决这些问题。
此外，通过单独的develop分支，您无需担心开发人员在部署生产时向其提交代码。更不用说通过单独的develop分支，QA的工作变得更加容易。