这似乎是一个简单的问题，但在办公室引起了令人惊讶的对话。 开发人员应共享一个分支，例如还是每个开发人员都应该使用自己的分支，并且如果需要与其他团队成员进行协作，则应为此目的使用一个单独的分支（例如发布分支）？
我还没有看到任何主要的分支策略可以直接解决这个问题（Git Flow，GitHub Flow或GitLab Flow）。共享一个功能分支可使多个开发人员轻松协作，并且在创建和/或合并请求请求时可以对提交/消息进行任何清理。但是，即使是2个开发人员，在同一个分支上工作时（例如，如果其中一个使用合并，而另一个使用重新设置基准。这里有最佳实践建议吗？
答案 0 :(得分：1)
尽管我认为这个问题是主观的，但我认为它更多地取决于您认为是“功能”的东西。例如，如果您具有一个足够广泛的“功能”，可以让两个或多个开发人员同时解决该功能，那么我不认为这是一个功能，而是将其视为epic
在每个“功能”仅限于一个开发人员的情况下，我会细分此类工作。这样，单个开发人员就可以在自己的feature分支上独立地使用这些功能，然后在工作完成后合并回develop。
应该以这样一种方式来分割工作（并且应该对项目进行结构化）：开发人员几乎永远不需要同时处理相同的文件，尽管如果需要两个开发人员在完全相同的区域上串联工作，开发人员B始终可以将develop合并回到其feature分支中以获取最新更改。
但是，我建议不要将开发人员A的feature分支直接合并到开发人员B的feature分支中。这样做实际上是在说功能B依赖于功能A。出于同样的原因，我也建议您不要使用“联合”分支。
在这种情况下，我建议对特征B进行延迟工作；您将未知的风险引入功能B的开发中，并匆忙开发功能A。这可能导致功能A的测试不足（可以通过shifting to the left解决，该测试在分支上完成本身，然后再部署回develop）。