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