Tricky Git Tips
前言
- 以下内容不牵涉 Git 的内部实现原理，阅读正文将花费您大约15分钟。
- 文中的所有 Git 命令省略了参数，完整调用请查阅官方文档。
- 本文基于一次组内分享的内容整理，希望对各位有所帮助。
作为开发者，使用 Git 作为项目的代码控制系统已经是必备技能了（当然，还有本文的MarkDown），而日常工作中的你是否只停留在无尽的 pull 与 push 中呢？
下面就来介绍 Git 中的几种实用命令，相信会对你今后可能遇到的实际工作场景带来实质性的效率提升。
介绍命令之前，首先我们先需要了解下 Git 中操作区域的概念。
操作区域
Git 的操作区域和 vi 中的缓冲区的概念很类似，不同的 Git 命令会在不同的操作区域中工作。
如图所示，Git的 add 操作会将文件的修改记录保存在暂存区，之后进行的 commit 操作会将暂存区的修改内容全部提交到历史区，最后进行的 push 操作将会把本地的操作记录推送到远程仓库中去。
之所以此处远程库的背景色使用了暗色调，是因为推送到远程库的代码是需要你“负责”的，一旦发布即是历史的诞生，请对 push 的操作保持敬畏和责任感。同时这里也牵涉到 Git 中提交哲学的概念。
提交哲学
我们可以根据每个提交的粒度大小，我们可以将 Git 中的提交方式划分为两种派别。
- 现实化提交：尽快提交每个修改，保证提交历史记录中记录了所有的变更细节。
- 理想化提交：清理不好的中间决策，每次提交保证合乎逻辑，改动具有完整性。
这里没有最优的实践，我们可以在一个项目中同时存在两种提交风格，我们也可以在 push 到远程仓库之前，整理历史区中的提交记录，通过重新排序、合并、删除甚至添加新提交，使得原先的现实化提交转化为理想化提交，这完全取决于自己的喜好和项目策略。不过请记住，推送到远程库的提交是已发生的历史，是“不可变更”的。
拉取代码
既然 Git 的各个工作区域是逐级向上提交的，那我们如何获取各个工作操作区域的代码呢？
使用如下图中的三条命令即可。
工作场景
好了，通过上面我们了解了 Git 的操作区域和提交哲学，下面就介绍 Git 命令在实际工作场景中的运用。
对付强迫症
控几不住我记几， 怕断电怕死机总想提交怎么办？
git commit –amend
git commit --amend命令可以在我们 push 代码之前修改最后一次提交内容。
如图所示，常规 commit 会在历史中产生两次提交记录，而 amend 会对最后一次提交内容进行覆盖。
对付组员
现在组内有很多业务线，大家在不同分支上开发，开发到一半想基于某条分支最新的代码进行开发怎么办？
git rebase
rebase 命令正是用来改变当前提交的基础而生的。
对付产品经理
产品总是改需求，开发节奏有点乱怎么办？
git cherry-pick
cherry-pick 命令可以引入其它分支上特定的提交来应用到当前分支。
如图我们可以摘取指定分支中的某个“需求”实现来应用到当前分支。另外一种场景是用该命令提取修复分支上提交的某个bug修复代码。
对付测试
还在写代码，测试又来提bug了，改到一半的代码怎么办？
git stash
Git 通过 stash 命令可以暂存我们的改动文件，同时使用对应的 pop 可拿出历史的改动。值得注意的是暂存没有分支的概念，在当前分支暂存的文件可以在其它分支中取出。
其他
说了这么多，不妨去练练手，下面是几个 Git 命令的在线练习网站。