我们的 git 工作流程接近这里解释的一个成功的 Git 分支模型
让我们忽略发布和修补程序分支，因为它们与此问题无关。我现在有三个分支：
现在我在团队 X 中，我们开始开发一个名为feature/A. 与此同时，Y 团队正在开发其他功能分支feature/B。Y 队也完成了feature/C，并且feature/D
在这里，我处于一个奇怪的位置。我需要跟上develop分支，因为 Y 团队已经在那里合并了。我还需要跟上“功能/A”分支，因为其他团队成员正在做出改变。
我最喜欢的跟上变化的方式——rebase因为我需要在两个不同的分支中不断地变基，所以会带来很多麻烦。
merge以某种方式工作，但我仍然认为必须有更好的方法。
你如何使用这样的设置？我确实尝试搜索人们如何使用它，但找不到任何线索。
链接中的上述工作流程也没有明确说明此类设置。
托管在github上。
通常，一旦你启动了一个特性分支，你就会与其他开发线隔离开来。因此，在处理功能 A 时，默认情况下，您应该永远不要从develop其他分支或其他分支（尤其是其他功能分支）中提取更改。如果您的开发需要进行一些更改develop才能继续进行集成（例如，当您添加了一些您依赖的东西时），那么您可以合并一次develop到您的分支中。但总的来说，你会尽量避免这种情况，以保持开发分离。然后，当你完成后，你将你的特性分支合并到develop，特性分支就可以走了。
在团队中工作时，重新定位从来都不是一个好主意。一旦你发布了一些东西，你就永远不要再变基了。这样做将创建具有新哈希的新提交对象，因此您的分支将指向不同的对象，从而破坏其他所有人的历史记录。您可以在推送之前在本地进行 rebase，例如清理您自己的提交。但除此之外，最好不要这样做。
除此之外，您可以只使用git fetch从远程存储库中获取所有更改。获取将更新您的远程分支，即origin/master,等。因此origin/develop，origin/feature/A当您想要参考远程存储库的当前状态时，您可以使用远程分支。但是，您的本地分支机构 ( master, develop) 不会自动更新。除非您与他们合作，否则您不一定需要更新它们。如果你这样做了，只需检查它们，然后与它们的远程分支快速合并。
你不应该跟上develop- 只有feature/A. X 团队的负责人（可能是戴不同帽子的你）应该确保它feature/A是最新的develop。这样，每个分支都会重新定位到单个分支。