共计 993 个字符，预计需要花费 3 分钟才能阅读完成。
想象一下：你刚提交到本地仓库的一个 commit，你在工作区又发现有点错误，此时再 commit 一次完全没毛病，但为了这一点错误，你又产生一个 commit 记录。不够优雅！更好的方法是
git commit --amend // amend 的意思是修正 当你修改好新发现的小错误以后 执行上面的命令，这将会把上次 commit 的内容和暂存区内容合并 并把上次 commit 记录替换掉。
对于你刚完美的把小错误修复以后可以执行
git add file
git commit --amend 需要注意的有一点：commit --amend 并不是直接修改原 commit 的内容，而是生成一条新的 commit。
Rebase 变基，不喜欢 branch 复杂的分支？只想要线性的提交记录？
前面我们讨论到，Feature branch 工作流。可以从一次 commit 中产生一个分支 来并行进行开发项目，开发完毕后通过 git merge 将分支上的内容合并混入到主线分支 master 上，但 merge 会在提交历史上完整留下记录。当回头看时，会觉得提交历史比较复杂。
那有米有一种方式，能把提交历史线性的变化，即使原本是带有分支记录的。
git checkout feature // 进入需要被变基的分支
git rebase master // 将当前分支的基础点设置到目标分支的最新一次 master: A → B → C
↘
feature: D → E
执行 git checkout feature && git rebase master 后：
plaintext
master: A → B → C（⚠️ master 完全没变化！还是停在 C）↘
feature: D'→ E'（feature 基于 C 重新排列，最新到 E'）此时，我们再执行一次 merge 操作
git checkout master // 切回主线分支
git merge feature // merge 一次 这样我们才算真正完成了 将原本复杂的带分支的提交历史，变成了只有一条线的提交记录。
Git 发现 feature 的基础就是 master 的最新提交（C），所以不会生成任何新的合并 commit，只是把 master 的指针直接“挪”到 feature 的最新 commit（E’）：
小结
本节介绍的是 rebase 指令，它可以改变 commit 序列的基础点。它的使用方式很简单：
git rebase 目标基础点 需要说明的是，rebase 是站在需要被 rebase 的 commit 上进行操作，这点和 merge 是不同的。
