diff --git a/sources/重写项目历史.md b/sources/重写项目历史.md
index 71ec41b..7556518 100644
--- a/sources/重写项目历史.md
+++ b/sources/重写项目历史.md
@@ -36,9 +36,9 @@ git commit --amend
 
 修复过的提交事实上是全新的提交，之前的提交会被移除出项目历史。这和重设公共快照的后果是一样的。如果你修复了其他开发者在之后继续开发的一个提交，看上去他们的工作基础从项目历史中消失了一样。对于在这上面的开发者来说这是很困惑的，而且很难恢复。
 
-### 例子
+### 栗子
 
-下面这个例子展示了 Git 开发工作流中的一个常见情形。我们编辑了一些希望在同一个快照中提交的文件，但我们忘记添加了其中的一个。修复错误只需要缓存那个文件并且用 `--amend` 标记提交：
+下面这个🌰展示了 Git 开发工作流中的一个常见情形。我们编辑了一些希望在同一个快照中提交的文件，但我们忘记添加了其中的一个。修复错误只需要缓存那个文件并且用 `--amend` 标记提交：
 
 ```
 # 编辑 hello.py 和 main.py
@@ -84,9 +84,9 @@ rebase 是将上游更改合并进本地仓库的通常方法。你每次想查
 
 和我们讨论过的 `git commit --amend` 和 `git reset` 一样，你永远不应该 rebase 那些已经推送到公共仓库的提交。rebase 会用新的提交替换旧的提交，你的项目历史会像突然消失了一样。
 
-### 例子
+### 栗子
 
-下面这个例子同时使用 git rebase 和 git merge 来保持线性的项目历史。这是一个确认你的合并都是快速向前的方法。
+下面这个🌰同时使用 git rebase 和 git merge 来保持线性的项目历史。这是一个确认你的合并都是快速向前的方法。
 
 ```
 # 开始新的功能分支
@@ -140,9 +140,9 @@ git rebase -i <base>
 
 大多数开发者喜欢在并入主代码库之前用交互式 rebase 来完善他们的 feature 分支。他们可以将不重要的提交合在一起，删除不需要的，确保所有东西在提交到「正式」的项目历史前都是整齐的。对其他人来说，这个功能的开发看上去是由一系列精心安排的提交组成的。
 
-### 例子
+### 栗子
 
-下面这个例子是 `非交互式rebae` 一节中例子的可交互升级版本。
+下面这个🌰是 `非交互式rebae` 一节中🌰的可交互升级版本。
 
 ```
 # 开始新的功能分支
@@ -213,9 +213,9 @@ git reflog --relative-date
 
 每次当前的 HEAD 更新时（如切换分支、拉取新更改、重写历史或只是添加新的提交），引用日志都会添加一个新条目。
 
-### 例子
+### 栗子
 
-为了理解 `git reflog`，我们来看一个例子。
+为了理解 `git reflog`，我们来看一个🌰。
 
 ```
 0a2e358 HEAD@{0}: reset: moving to HEAD~2