此列表准确定义了执行 rebase 后分支的外观。通过更改 pick 命令或重新排序条目，你可以使分支的历史记录看起来像你想要的任何内容。例如，如果第二次提交 fix 了第一次提交中的一个小问题，您可以使用以下 fixup 命令将它们浓缩为一个提交：
pick 33d5b7a Message for commit #1 fixup 9480b3d Message for commit #2 pick 5c67e61 Message for commit #3保存并关闭文件时，Git将根据您的指示执行 rebase，从而产生如下所示的项目历史记录：
消除这种无意义的提交使你的功能历史更容易理解。这是 git merge 根本无法做到的事情。至于 commits 条目前的 pick、fixup、squash 等命令，在 git 目录执行 git rebase -i 即可查看到，大家按需重排或合并提交即可，注释说明非常清晰，在此不做过多说明:
Rebase 的黄金法则一旦你理解了什么是 rebase，最重要的是要学习什么时候不能使用它。git rebase 的黄金法则是永远不要在公共分支上使用它。
例如，想想如果你 rebase master 分支到 feature 分支之上会发生什么：
rebase 将所有 master 分支上的提交移动 feature 分支的顶端。问题是这只发生在 你自己 的存储库中。所有其他开发人员仍在使用原始版本的 master。由于 rebase 导致全新 commit，Git 会认为你的 master 分支历史与其他人的历史不同。
此时，同步两个 master 分支的唯一方法是将它们合并在一起，但是这样会产生额外的合并提交和两组包含相同更改的提交（原始提交和通过 rebase 更改的分支提交）。不用说，这是一个令人非常困惑的情况。
因此，在你运行 git rebase 命令之前，总是问自己，还有其他人在用这个分支吗？ 如果答案是肯定的，那就把你的手从键盘上移开，开始考虑采用非破坏性的方式进行改变（例如，git revert 命令）。否则，你可以随心所欲地重写历史记录。
Force Push如果你尝试将 rebase 了的 master 分支推送回 remote repository，Git 将阻止你这样做，因为它会与远程master 分支冲突。但是，你可以通过传递 --force 标志来强制推送，如下所示：
# Be very careful with this command! git push --force这样你自己 repository 的内容将覆盖远程 master分支的内容，但这会使团队的其他成员感到困惑。因此，只有在确切知道自己在做什么时才要非常小心地使用此命令。
如果没有人在 feature branch 上作出更改，你可以使用 force push 将本地内容推送到 remote repository 做清理工作
工作流程演练rebase 可以根据你所在团队的需要方便的整合到现有的 Git 工作流程中。在本节中，我们将了解 rebase 在功能开发的各个阶段可以提供的好处。
在任何工作流程中，利用 git rebase 是为每个功能创建专用分支。这为你提供了必要的分支，以安全地利用 rebase：
将 rebase 纳入工作流程的最佳方法之一是清理本地正在进行的功能。通过定期执行交互式 rebase，你可以确保功能中的每个提交都具有针对性和意义。这可以使你在编写代码时无需担心将其分解为隔离的提交(多个提交)，你可以在事后修复整合它。
使用 git rebase 时，有两种情况：feature 父分支（例如 master ）的提交，或在 feature 中的早期提交。我们在 交互式 Rebase 部分已经介绍了第一种情况的示例。我们来看后一种情况，当你只需要修复最后几次提交时，以下命令仅做最后 3 次提交的交互式 rebase。
git checkout feature git rebase -i HEAD~3通过指定 HEAD~3 ，你实际上并没有移动分支，你只是交互式地重写其后的3个提交。请注意，这不会将上游更改合并到 feature 分支中。
如果要使用此方法重写整个功能，git merge-base 命令可用于查找 feature 分支的原始 base。以下内容返回原始 base 的提交ID，然后你可以将其传递给 git rebase：
git merge-base feature master交互式 rebase 的使用是引入git rebase 工作流的好方法，因为它只影响本地分支。其他开发人员唯一能看到的就是你提交的最终版，这应该是一个简洁易懂易跟踪的分支历史记录。