mergingmaster到功能分支和host上的rebasing特征分支在所有可能的情况下都有相同的最终结果吗？还是在特定的上下文中我应该支持其中一个？为什么？我知道合并会产生额外的提交，以更好地理解历史，但我更感兴趣的是操作的实际结果以及成功的可能性。那么，这有实际的区别吗？或者我可以根据惯例选择其中一种方法（甚至可以兼而有之）？
此外，我需要多久同步一次feature branch和master？每次我返回开发特定功能时，merge/rebase是一种好的做法吗？还是应该尽可能长时间地将该功能与架构的其他部分隔离？
当多个功能彼此高度依赖时，如何应对这种情况？功能应该作为一个单独的功能分支来开发，还是作为一个不同的功能分支合并到公共功能分支？比方说，在Spring framework中，许多配置和层是相互依赖的。保持完整和同步的常见工作流程是什么？
合并和重定基以完全不同的方式解决相同的问题。与重新定基不同，合并是非破坏性的。然而，只要你遵循回扣的黄金法则，一切都会很好，你可以享受整洁的承诺历史。规则是"不要对公共分支机构使用重新定基。"
此外，我需要多久将功能分支与master同步一次？
这主要是品味问题。正如Pro-Git中所解释的，有不同的分支工作流可供选择。
重新分配和合并在所有情况下都不平等，因为当您在master上重新建立基础时，您实际上是在master上进行新的提交，这将具有不同的id和内容。这就是为什么不重新调整公共分支机构的基础很重要。然而，重新定基可以给你一个干净的历史。
至于问题的分支部分：看起来您正在寻找的是一个分支模型。最流行的分支模型之一是gitflow，它使用合并模型。
http://nvie.com/posts/a-successful-git-branching-model/
git流模型的本质是使用master、release、develop和feature分支（以及其他分支）来组织代码的状态。有了这个模型，应该很容易判断何时合并，因为它将处于某些阶段，例如：一个功能已经完成，或者你将要进行下一个发布。