使用两个共享活动分支改善git工作流程

Question

我们的git工作流程接近于此处解释的A successful Git branching model

让我们忽略发布和修补程序分支，因为它们与此问题无关。我现在有三个分支机构：

• 主
• 开发
• 特征

现在我在X队，我们开始研究名为feature/A的功能分支。与此同时，Y队正在研究其他功能分支feature/B。 Y队也完成了feature/C和feature/D

在这里，我处于一个奇怪的位置。我需要跟上develop分支，因为Y团队在那里合并了。我还需要跟上“功能/ A”分支，因为其他团队成员正在进行更改。

我追求变化的首选方式 - rebase会导致很多麻烦，因为我需要不断在两个不同的分支中进行变革。

merge在某种程度上有效，但我仍然认为必须有更好的方法。

您如何使用此类设置？我确实尝试过搜索人们如何使用它，但找不到任何线索。

链接中的上述工作流程也没有明确说明此类设置。

托管在github上。

Answer 1

通常，只要启动功能分支，您就会与其他开发线隔离。因此，在处理功能A时，您应该默认情况下永远不会从develop或其他分支（尤其是其他功能分支）中获取更改。如果您的开发需要对develop进行一些更改，然后才能继续（例如，当您依赖添加的内容时），那么您可以从develop合并一次到您的分支。但总的来说，你会试着避免这种情况，以保持开发分离。然后，完成后，将功能分支合并到develop，功能分支就可以了。

在团队中工作时，重新定位绝不是一个好主意。一旦发布了某些内容，您应该永远再次对其进行重新定义。这样做会创建带有新哈希的新提交对象，因此您的分支将指向不同的对象，这些对象会破坏其他人的历史记录。您可以在推送之前在本地进行rebase，例如清理自己的提交。但除此之外，最好不要这样做。

除此之外，您只需使用git fetch从远程存储库中获取所有更改。提取将更新您的远程分支，即origin/master，origin/develop，origin/feature/A等。因此，只要您想要引用远程存储库的当前状态，就可以使用远程分支。您的本地分支机构（master，develop）不会自动更新。除非您正在使用它们，否则无论如何都不一定需要更新它们。如果你这样做，只需检查它们，并快速合并它们的远程分支。

Answer 2

您不应该与develop保持同步 - 仅限于feature/A。 X队的领导者（可能是你戴着不同的帽子）应确保feature/A与develop保持同步。这样，每个分支都会在一个分支上进行重新定位。