在开篇章节中，我们知道了 feature 分支如何使用 git merge 或 git rebase 合并 master 分支的上游提交。当 rebasing 通过移动你的 feature 分支到 master 分支的头部来创建一个线性历史时，Merging 是一个用于保护你仓库的整个历史记录的安全选项。
git rebase 的作用与本地清除相似（能够同时被执行），但是在此过程中，它合并了 master 的上游提交。
牢记，远程分支取代 master 分支是完全合法的。这发生在其他开发者在同一个 feature 分支上协作时和你需要合并他们的更改到你的仓库中时。
举例说明，如果你和一个名为 John 的开发人员添加了对 feature 分支的提交，从 John 的仓库中获取远程 feature 分支后，你的仓库看起来像如下所示：
你可以用与 master 分支集成上游更改相同的方法来解决这个分叉：或者你本地的 feature 分支与 john/feature 分支合并，或者 rebase 你本地 feature 分支到 john/feature 分支的头部。
请注意，任何事情在未更改之前，rebase 不能违反 Rebasing 的黄金法则 ，因为 feature 仅仅移动了本地提交。这就好像是在说，“将我的更改添加到 John 已经完成了的操作中。” 在大多数情况下，这比通过合并提交与远程分支同步更为直观。
默认情况下， git pull 命令执行合并，但是你可以强制通过使用 rebase 的 --rebase 选项整合远程分支。
使用 Pull 请求检验 feature 分支如果你使用 Pull 请求作为代码的审计过程，创建的 pull 请求之后，你需要避免使用 git rebase 。一旦你发出 pull 请求，其他开发人员就能看到你的提交，这就意味着它是一个公有分支。重写它的历史记录将使 Git 和你的队友无法追踪到任何添加到 feature 分支上的后续提交。
任何来自其他开发者的更改需要使用 git merge 取代 git rebase 来被合并。
为此，在提交你的 pull 请求之前，使用交互式 rebase 清理你的代码，通常是一个好主意。
整合认可的 feature在 feature 分支被你的团队认可之后，在使用 git merge 整合 feature 分支到主代码库之前，你有一个 rebasing feature 分支到 master 分支的选项。
合并上游更改到 feature 分支是一个类似的情况，但是，自从你不被允许在 master 中重写提交，你最后不得不使用 git merge 来整合 feature 分支。然而，通过在合并之前执行 rebase 确保 merge 将快速进行，形成完美的线性历史。这也给了你在 pull 请求期间将任何后续提交塞入到 feature 分支中的机会。
如果你对 git rebase 感到不太舒服，你可以在临时分支中一直执行 rebase。那样，如果你一不小心搞砸了你的 feature 分支历史记录，你可以多次检查原始分支。例如：
git checkout feature git checkout -b temporary-branch git rebase -i master # [Clean up the history] git checkout master git merge temporary-branch 总结在你开始 rebasing 你的分支之前，这是所有你真正需要知道：如果您想要一个没有不必要的干净的合并提交的线性历史记录，你应该争取 git rebase 代替 git merge 整合来自另一个分支的改变。
另一方面，如果你想保存你项目的完整历史并且避免重写公有提交的风险，你可以坚持使用 git merge 。任何一个选项都是完全有效的，至少现在你是有选择性的利用 git rebase 的好处。