像这样排除不重要的提交使你的特性历史相当易懂。这一点是 git merge 无法比拟的。
Rebasing 的黄金规则一旦你明白什么是 rebasing ，最重要的事情是学习什么时候不用它。 git rebase 的黄金法则是永远不要在公有分支上使用它。
举例说，想象一下如果你将 master 分支合并到 feature 分支上会发生什么：
rebase 操作将 master 中所有提交移动到 feature 的头部，但问题是这一切都发生在你的仓库中。其他开发者依然在原来的 master 分支上继续工作。自从 rebasing 产生了全新的提交，Git 将会认为你的 master 分支的历史记录与其他人的历史记录不同。
使两个 master 分支 同步的唯一方法是将他们合并到一起，导致出现一个额外的合并操作和两组都包含相同改变（最原始的那个，和那些来自你重新建立的分支）的提交。不用说，这是一个非常混乱的场景。
因此，在你运行 git rebase 之前，一定要问自己，“还有其他人在看这个分支吗？”，如果回答是肯定的，那么把你的手从键盘上拿开并开始考虑让你的改变没有破坏性（例如， git revert 命令）。否则，你可以随心所欲地重写历史。
Force-Pushing如果你尝试将合并的 master 分支推送到远程库中，Git 将防止你这样做，因为它与远程 master 分支有冲突。但是，你可以通过传递 --force 标志来强制推送，就像这样：
# Be very careful with this command! git push --force该操作会将远程仓库的 master 分支替换为 rebase 过的 master 分支，这会给团队的其他成员带来困扰。因此，当你确切的知道你要做什么的时候，才要非常小心的使用这些命令。
推送一个私有新特性分支到远程仓库（例如，用于备份）。这就好像是说，“哎呦，我不想推送 feature 分支的原始版本，拿当前的版本替换吧。”再强调一次，没有人在 feature 分支的原始版本中工作是很重要的。
工作流演练Rebasing 能够根据团队的需要或多或少的被合并到你现存的 Git 工作流 中。在这个选项中，我们将检查 rebasing 提供在不同阶段的 feature 分支开发的好处。
在任何工作流中，首先第一步是利用 git rebase 为每一个 feature 创建一个专用的分支。这给你必要分支结构来安全使用 rebasing ：
最好的方法之一是合并 rebasing 到你的 工作流 以此来清理本地正在进行的 feature 分支。通过定期的执行一个交互式的 rebase ，你可以确保每一个在你的 feature 分支中的提交是集中且有意义的。这将让你编写你自己的代码而不需要在独立提交中担心破坏它—你可以在事后修复它。
当调用 git rebase ，对于新的分支你有两个选项：feature 父类分支（举例说，master 分支），或者在你的 feature 分支中较早的提交。我们查看了在 交互式的 Rebasing 章节中首个选项的示例 。当你仅仅需要修复最新提交时，后者的选择最好。举例说，交互式 rebase 的最后3次提交显示如下：
git checkout feature git rebase -i HEAD~3通过指定 HEAD~3 作为新的基础，事实上你并没有移动分支—你只是交互式的重写了接下来的3次提交。请注意，这不会将上游更改合并到 feature 分支。
如果你想使用这个方法重写整个 feature， git merge-base 命令对于找到 feature 分支的原始起始点非常有用。以下返回原始起始点的提交 ID ，然后传递给 git rebase ：
git merge-base feature master交互式 rebasing 的作用在于当他仅仅影响本地分支时，它是一个 引进 git rebase 到工作流中的好方式。其他开发人员唯一能看到的是你最后提交的成果，这应该是一个简单且易于理解的 feature 分支历史记录。
但是在刚开始，这仅仅只为私有 feature 分支工作。如果你借助相同 feature 分支与其他开发者协作，分支是共有的，你也不被允许重写它的历史记录。
没有 git merge 之外的其他选择时可以使用交互式 rebase 来清除本地提交。
合并上游更改到 Feature 中