merging master 是否进入 feature 分支 和 master 上的rebasing feature 分支 是否相同最终导致每种可能的情况，还是我应该在特定情况下偏爱一种或另一种，为什么？我知道合并会创建额外的提交以更好地理解历史，但我对操作的实际结果以及成功的可能性更感兴趣。那么是否存在实际差异，或者我可以根据约定选择任何一种方法（或者甚至使用它们都包含）？
另外，我需要多久将feature branch 与master 同步一次？每次我回来开发特定功能时，merge/rebase 是一个好习惯，还是应该尽可能长时间地将该功能与架构的其余部分隔离？
当多个功能相互高度依赖时，如何确定范围？应该将功能开发为单个功能分支，还是作为合并到公共功能分支的不同功能分支？可以说，在Spring framework 中，许多配置和层相互依赖。保持所有内容完整和同步的常见工作流程是什么？
【问题讨论】：
标签： git version-control merge rebase
合并和变基都以非常不同的方式解决相同的问题。与变基不同，合并是非破坏性的。但是，只要您遵循变基的黄金法则，一切都会正常工作，并且您可以享受整洁的提交历史。规则是“不要对公共分支使用变基。”
另外，我应该多久将功能分支与 master 同步一次？
这主要是口味问题。正如Pro Git 中所述，可以选择不同的分支工作流程。
【讨论】：
rebase 的危险。如果我在master 的未发布 提交上rebase 本地分支，此时发布分支然后决定将master 重置为origin/master。现在，如果有人将该分支与master 合并，那将是一团糟，对吧？一个黄金法则是否可以是，仅基于已发布的提交。
rebase 合并到 master 的分支是否安全，并且由于某种原因以后继续工作？
变基和合并并非在所有情况下都是相等的，因为当您在 master 上变基时，您实际上是在 master 之上进行新的提交，这将具有不同的 id 和内容。这就是为什么不要对公共分支进行变基很重要的原因。然而，变基可以给你一个很好的干净的历史。
至于问题的分支部分：看来您正在寻找的是一个分支模型。最流行的分支模型之一是使用合并模型的 git flow。
http://nvie.com/posts/a-successful-git-branching-model/
git 流模型的本质是使用主分支、发布分支、开发分支和特性分支（以及其他分支）来组织代码所处的状态。使用这个模型应该很容易判断何时合并，因为它将处于某些阶段，例如：功能已完成或您将要发布下一个版本。
【讨论】：
merge develop 不时分支到 feature 分支有意义。将feature 与基础设施的其余部分尽可能长时间地隔离，并且仅在依赖项要求时才将merge 或rebase 保持隔离是一个好的约定吗？与多个依赖公共feature 分支相同的困境：可以将它们相互合并，还是先合并开发？我可能想多了，但我想了解整个情况。