1）团队可能对此有所不同，因为有些人认为“不必要的合并”使历史变得丑陋，但我认为合并develop到功能分支没有问题。如果您认为它使历史更清晰（并且尚未推送功能分支），另一种方法是将功能分支向前重新设置，但这可能会破坏功能分支上的中间提交。
2) 不完整的功能不应合并到develop. develop应该随时准备发布。在功能分支之间干净地共享更改很棘手（并且，在具有小故事/功能的合理敏捷方法中，通常是不必要的）。大多数方法都涉及一些妥协。见下文。
3）我不确定你为什么会看到这种行为；可能需要有关您如何尝试合并的更多信息。您可以通过检查分支并执行类似操作来撤消合并（最好是在没有推送合并的情况下完成）git reset --hard HEAD^
好的，如果需要，如何共享代码？好吧，如果你接受我的建议不要合并A到develop，你可能会想“我可以直接合并A到B？”。嗯，这比合并到develop很快要好，但这意味着B不能安全地合并到develop直到A已经（因为它会携带 的部分实现A）。
如果A还没有被推送，那么您可能会执行交互式 rebaseA以将B依赖于的更改移动到 的开头A，然后 rebaseB到具有常见更改的提交上。但这可能涉及拆分提交，并且可能会创建中断的中间状态，并且取决于尚未推送的分支（或者每个人都必须从上游 rebase 中恢复）......这一切都不容易做到。
从另一种选择是摘樱桃的变化A上B。这也是一种变基操作，但它保留所有现有提交的原样（因此不必担心是否已推送）。但是，如果共享更改是在也有其他更改的提交中，这仍然不是那么容易；并且在将功能合并回develop.
在周围，最好尽可能避免这种情况。如果特性 B 依赖于特性 A，那么可能会推迟特性 B，直到特性 A 被正确地合并到develop某个东西上。