关于缓存区
（2021年11月底）经过我自己实际工作的经验，我认为应该是在一个小步成功是使用 add 添加到缓存区，而得到一个完整的大步成功之后，将缓存区中的内容提交。比如我2021年11月做ActionSheet的样式改版的时候，在文字的Padding上吃了大亏。回想一下应该是保证小步-大步这样的节奏逐渐前进的。比如任务是做一个圆角的按钮，同时有好多种字色、按钮颜色。这个任务已经足够小了，不应该再拆成字色一个提交、背景色一个提交、圆角一个提交，这样提交太多一样会导致rebase或者revert或者cherry-pick的时候过于恶心，而且它们是针对同一个非常小组件的改动，理应是在一个commit中。那么做完圆角效果的时候就应该add一下。万一后面背景色什么的出错了，你可以把未缓存的直接全部丢弃，而不需要逐行去看哪些是你需要的。在ActionSheet的Layout级别调整上，这也是一个大问题。同时在编译运行发现效果还不错的时候，大概执行了10%-20%的用例就可以add，保证你目前关注的主链路是成功前进了的，但是没有办法保证没带来次生影响。在多次add积累到一个commit之后，需要进行一次30%-50%用例的覆盖，保证这次commit大概率是没有任何错的，最后提测之前要进行100%的用例覆盖。
关于 rebase 和 merge 同步主干
（2021年11月底）从我实习开始算起，我用rebase 同步主干已经有6个月的历史了，这个星期才开始使用merge进行同步。说一下这些方法的不同：
rebase 的方法
git checkout master
git pull master（基于持续集成）
git checkout develop 分支
git rebase master
记住 git rebase master 的含义是“使得从 master 分支的指针重新成为 base ”，也就是从 master 的最新版本重新拉一个分支出来，然后回放你的各个 commit。缺陷是每个 commit 可能都会导致一次合并冲突，你每次都需要进行解合并冲突，假如 commit 数量多了，那么 rebase 的代价会很大。而且 rebase 会导致需要 git push -f 破坏掉远端的提交，和别人共享分支时这样做属于乱搞，非常不好。优点是假如运气好冲突比较少的话，你可以重新在分支的最前方看到你的提交，你可以方便的在本地回滚、改日志、乱搞。
merge 的方法
git checkout master
git pull master（基于持续集成）
git checkout develop
git merge master
merge master 的含义是把 master merge 进当前分支。缺点是会创建一个合并节点，这个合并节点一般同时包含了解决合并冲突的过程，这个过程是一劳永逸的，这一次解决好了之后，后续再 merge 之类的都不会再涉及此次合并冲突。
结论：rebase 适合用来自己乱搞，特别是分支名乱起、commit 日志乱写、commit 乱提交乱 cherry-pick 的情况，搞歪门邪道的时候方便。
关于 push 和 pull
pull 的本意是先 fetch 上游分支的改动到本地，然后把上游分支的改动 merge 到当前的分支上，所以会出现一个合并节点。这也是 github 上 pull request 的意思，就是请求管理员（相当于远端）pull 自己的分支，这样就成功在远端创建一个合并节点，把你的改动弄进去了。（以合入目标分支为 master 为例）这和我们的 merge request 是相似的，不同点在于 pull request 是需要你在本地合入 master 分支，然后请求对方 pull 你的 master 分支（存疑）。merge request 是请求对方的 master 分支直接 merge 你的分支。
git pull -r
即 --rebase
使用 rebase 的方法 pull，取代 merge。这样当自己的提交会从上游的最新一个提交后面重新长出来。
git pull -p
即 --prune
在 fetch 之前把远端分支不再存在的本地追踪引用去除掉。常见于某些人把远端改来改去的情况，有时候不加这个参数就拉不下来。
push -f
强行推送。常见于 rebase 乱搞之后。