通过11个命令来精通git

上周说让我做一次开发团队 git 使用的培训，一时不知从何说起，后来找了两个同事聊了聊，观察了他们的使用，发现了几个问题：

• 大多数同事都只用 add、commit、push 几个命令，也只会这几个命令
• 开发只用一个分支，graph 混乱，遇到冲突不知道如何解决
• 以 cp 文件的形式来传递修改 …

这完全是自己砍掉了 git 的双脚和双手，很多人使用git要么是公司要求用，要么是看别人用，并没有意识到 git 作为工具，能给开发者带来了多少的便利。

从使用入手，通过使用来学习，我觉得是学习最快的方式。我从我的 terminal 的 history 中找出了使用靠前的几个 git 命令，我也是开发者，所以我想大部分小伙伴都会遇到跟我一样的使用场景。

为了方便演示，我首先初始化一个空仓：

1 git commit

git commit 用来提交当前工作空间的修改内容。
commit 是 git 中最重要的内容，因为提交时git仓库中基本的单位，是后续修改，查找的基础。如何做好提交，是一门学问，那如何才算是好的提交呢？
首先，提交需要原子化，粒度要小，可以是一个函数、一个脚本，尽量一个提交只做一件事，不要把所有的修改，几十个文件，几百行代码放在一个commit中，这样后续代码维护也是问题。
其次，提交说明要写好。提交说明包括提交主题和提交信息两部分。主题就是这次提交主要干了什么，尽量保持在50字节以内（Gerrit 的commit_log检查插件似乎有着稍微宽泛一些的要求）。 这是因为对于像 Linux、Git 这样的开源项目，是以邮件列表作为代码评审的平台，提交主题要作为邮件的标题，而邮件标题本身有长度上的限制。 既然提到提交主题作为邮件标题，还要提及一点，你见过在邮件标题的结尾写句号么？所以提说明的第一句结尾不要加标点符号。
提交主题后的空行 必须要在提交说明的第一行和后续的提交说明中间留一个空行！如果没有这个空行，很多 Git 客户端会将连续几行的提交说明合在一起作为提交描述。这样显然太糟了。
提交信息是提交说明的主体，要让评审者对提交信服，要为将来的代码维护者留下线索，提交说明要回答如下问题：

• What——要解决什么问题？什么情况下会发生？
• How——怎么样解决这个问题?
• Why——为什么这样解决是合理的，比其他解决方法更好?

git commit -m只是写short message的提交方式，应该用：git commit -se。
创建文件：

提交：