Git 真的很好用，但是 Git 的命令真的好复杂。简单整理一下，就当写个教程好了~

头图出自 夏空 太太所画的 多多良 小伞，可爱捏~ 那就来一曲小伞的个人曲吧

Git，熟悉又陌生的名字 ……

也许是所处环境的原因，我身边有很多人不知道 Git 是什么。他们都听过 Github，但很多却只知道上面有好多程序和程序员。虽然也没错，但是并不准确；而当我说我在用 Git 的时候，会有人把 Git 和 Github 混为一谈；很多人觉得 Git 很复杂，顺带觉得 Github 也很复杂…… 为此，我想分享一下我对 Git 和 Github 的理解，聊聊 Git 和 Github 都是什么。

所以，如果你不了解 Git 是什么，那我很荣幸能在这里向你简单介绍它。

所以到底什么是 Git？版本控制？啊？

所谓的 Git，它就是：

是的，事实就是这样。游戏存档。卡关的时候/做支线的时候/后悔的时候可以进度回溯的游戏存档。如果你在翻阅 ProGit 或者某些教程时不太明白什么是 版本控制系统，没关系，就是游戏存档（程序用）的比较花哨的名字。

不过，为了能高效地，更好地服务程序员，Git 自然有了一大票复杂的功能，且每个子功能还会做特别多的细分，另外对每个存档都可以有非常复杂 （麻烦） 的，细致 （啰嗦） 的控制。然而，这依旧不能让它摆脱它就是个存档系统的事实。

一旦你接受了这个设定，那么 Git 就其实没有多少秘密了。

OK，但是听你说好像很麻烦……

不得不承认的是，正如上面所说的那样，Git 的命令实际上可以非常地复杂。如果你愿意翻阅它的 man-page，你会发现内容出奇地长；而当你尝试用 git --help 来获取一些简单有效的信息的时候，很抱歉，git --help 只会告诉你你能怎么做，并伴随着看不太懂的 usage，却不太会告诉你怎么做能做什么。

然而，转折来了。首先，如果你受环境所限，只能从命令行操作 Git，待会儿介绍的四五个命令几乎就能覆盖 80% 的使用场景了。而如果你的环境支持你使用图形化的界面，那么如果不是命令行的忠实用户，完全可以挑个 GUI 程序，比如和 Github 集成度高的 Github Desktop，界面美观现代，功能也已经足够丰富，没必要和自己过不去。

所以，结论是：Git 很复杂，但是我们可以用的很简单呀。它很强大，很好，但这不影响我只需要那几个最基础的功能。最重要的是，当你需要更复杂的功能的时候，互联网永远是你的好朋友。你完全可以现场上网搜索，大概率会有来自 StackOverflow 的朋友向你答疑解惑（贴答案）（好几年前且点赞特别高的）。

So, don’t be afraid! Just try it!

行，但是 Git 和 Github 到底是什么关系？

这算是很常见的问题了。解释起来也很简单：Github 能提供云存档功能。就像 Steam 有游戏云存档一样，Git 也可以有个云存档。只不过，Steam 有个专门的服务器来帮你自动地存好你的游戏内容，而 Git 则可以允许你选择你喜欢的地方存你的代码存档。

而 Github，正是那个大部分程序员都喜欢的选择。不仅如此，Github 上传的存档还兼具展示功能，大家可以在 Github 上给自己喜欢的代码存档投票，也可以把别人的存档下载到自己电脑上，甚至可以尝试和别人一起组排。所以，说是交友网站，也未尝不可（也许）

那么我可以选择别的地方存放存档吗？当然可以！除了 Github，还有很多很多的 Git 服务提供商。你还可以 自建 Git 服务！甚至，Github 显得有些 “违背” Git 的初衷：分布式的存档存储。什么意思呢？Git 一开始是打算，让所有的代码开发者（玩家）都留一份存档，然后大家就可以一起攻略组排了。大家都保留一份源码，这不就相当于大家都做存储功能了吗？只不过随着合作要求的提高和开源社区的扩大，Github 这样一个公开自己代码的地方就这么自发地出现了。

总而言之，Git 是存档工具，Github 是大家上传/分享/讨论/合作云存档的地方。

好耶，我逐渐理解一切！

是这样的，Git 就是做这么个事儿。也许你会看到一些介绍一开始会提 Git 使用的技术多么先进，多么高效，多么体现开源精神，然后不明所以。然而 Git 就是做这么个代码存档的东西，为了使用它以期了解它的话，大框架就是这样的。

然而这里还是要提个醒：上面也许的确抓住了 Git 的核心目的，但是依旧是很粗糙的，非常概括性的。上面的文字只能帮助 了解 Git 是什么，并不能告诉你 Git 怎么做的。另外，使用 Git 的命令完成最基础的工作是很简单，但是在切实明白一条命令到底在做什么前，请最好不要盲目运行这条命令。实际上，要想运用好 Git 管理你的代码/项目，还是需要了解一些关于 Git 究竟在背后怎么做的知识的。

所以，如果你还对 Git 感兴趣，或者想把 Git 用起来的话，我们就来讲一些技术细节吧~

要怎么用 Git 存档？

想解答这个问题，我们不可避免地要接触一些没啥意思的概念。与其直接介绍它们，我们先来看看，日常开发会怎么使用 Git 吧。

Tig 的一天

Tig 是热爱 Minecraft 的忠实玩家。他很享受创造神的感觉，毕竟他就是被游戏名吸引而来的。今天他计划开展一个新的工作：制作一个百万刷铁机！

Oh no! Tig 的 Minecraft 除了点奇怪的问题！他被告知，Minecraft 的图形界面已经坏了，取而代之的，他可以用代码来操控角色并任意创造游戏中的物品，且他只能用 git 来做存档（究竟是谁干的，真坏呀）。Tig 感到心里五味杂陈：这还是 Minecraft 吗？然而他心中有一个信念：我一定要做好这个刷铁机，即便我能直接虚空点出来铁块！等游戏恢复的时候，就可以在这台刷铁机的基础上继续快乐玩耍啦！

于是，Tig 用 git init 创建了一个空世界的存档。然后就开始在存档里用代码一行行写他在这个世界里要做些什么……

过了一会儿，Tig 妈妈喊他要他吃午饭了。虽然不愿意，Tig 还是要先放下手上的工作。他打算先暂时保存一下，于是使用 git add . 来保存好自己手上的所有写好的代码。毕竟，他也不知道是不是有的地方有点问题，带会儿还要调一下，他现在也是被拉过去吃饭的。

吃完饭后还睡了个午觉，Tig 回来又写了一会儿。他对自己的成果很满意，因为他已经想办法把村里的刁民挪到了高空中了。这实在是不太容易，他不希望待会儿犯蠢丢掉这几个村民。于是他决定要存档。他先用 git add . 来保存所有文件的所有改动，然后用 git status 查看了改动的文件们。感觉没什么问题，他使用 git commit 来正式保存了这个存档。存档系统问他要他给自己的改动写个简述，他写了 村民挪好了，准备搭框架。

过了一个下午和一个晚上，Tig 终于在睡觉前把刷铁机搞好了！实在是一个无比伟大的创举，Tig 忍不住把它分享出去，也方便自己在其他电脑上继续工作。他创建了 Github 账号和一个仓库，并且用 git push 把这个存档放在了它的仓库里。然而睡前他还是想先在另一台电脑上先把存档下下来，于是使用 git clone <git-link> 来把仓库克隆到本地。

晚上躺在床上，他一想到以后就可以把存档用 git push 方便地推送到 Github 上，并且用 git pull 在另一台电脑上来获取最新的改动了，他就不自觉地笑出声，心里盘算着怎么在明天做一些改善，给刷铁机套个好看的壳子之类的……

可喜可贺，可喜可贺！~

所以，他都干了些啥？

Tig 的故事貌似有点无聊，毕竟，给 Git 硬套个背景，貌似有点牵强；更重要的是，谁家好人这么玩 Minecraft 呀！然而他用到的命令，几乎就是我平时常用的所有命令了。我们来总结一下吧。我们就不再多提游戏的事，毕竟好像都戳穿了是在写代码……

• git init

我们可以用 git init 来在本地创建/初始化一个 Git 仓库。这代表着，你打算用 Git 来管理这个文件夹了。很简单的命令，其实频率也很低，因为你很少反复初始化一个仓库。

• git add .

一个频率还挺高的命令。你在仓库内的修改，Git 都不会立马记录下来。他怕他立马记下来之后，随后用户又马上反悔。另外，这样立马就记录下来，反而和单纯的文件保存功能有所重叠了。

所以，当你觉得目前的进展还不错，你就可以用这个命令来 暂存 当前的所有修改。这里的 “暂存” 有两个意思：一是 Git 确实是把你的修改保存到了 暂存区 里，另一个则是你要是现在发现有个修改不太对，可以很方便的从暂存区里撤下来。

git add . 里的这个 . 就是当前目录的意思，也就是说这个目录下的所有文件我都要暂存起来。Git 会很聪明地只保存修改，这也是设计之初就确定的。如果你只想保存一部分，那就写他们的名字吧，或者写对应的目录，都可以，能定位到就好。

不过，总之，这个命令就是让你暂存当前所有修改的。

• git status

一个我很爱用的命令。可以向你报告当前暂存区的情况以及工作目录的情况。比如什么文件被修改了，哪些文件是新加的，谁被删除了，而这些改动里谁被暂存下来，又有哪些你没暂存下来。

如果你的 Git 是默认配置，他还会提醒你可以怎么撤回某些修改。跟着做就好了。

• git commit

当你对你的进度感到满意时，你就可以用 git commit 来提交你暂存区的东西了。所谓的提交，就是形成一个存档，你后续可以回来的一个存档。这个存档里你的仓库的模样会被冻结下来，当你回到这个提交时，一切都会回到当初的模样。非常的美好。

要注意的有两点，一是 git commit 只提交 暂存区 的内容。没被暂存的，还会在原地等待你先用 git add 暂存起来，或者等你撤回那些修改。二是，git commit 会要求你给这个提交留个注释。请不要省事瞎写个什么东西，因为未来的你可能会对瞎写注释的现在的你感到伤心。默认情况下，git commit 会打开你的文本编辑器然后让你开写，而如果你觉得很麻烦不想开编辑器，可以用 git commit -m "messages" 来把这行 messages 作为提交注释。

可以再补充两点：如果你提交过后发现因为小失误忘记暂存某些内容或者有些小改动的话，你可以在把改动加入暂存区后补充到这次提交里，用法则是 git commit --amend。另外，提交要慎重，因为提交过的内容就不是那么好修改了。你当然能改，但是相比 git add 到暂存区的内容而言，实在是要麻烦一些。

• git push

把你当前的内容推送到远程仓库里。如果你的仓库是用 git clone 获得的且你拥有这个仓库的修改权限，那么 git push 就可以简单直接地把 这条分支 的修改推送到远程。

我们这里还是先不讲什么分支，也先不谈远程协作之类的东西。不过就常用命令介绍来说，git push 算是比较常用且同样很简单的一个命令了。

• git clone

把 git 仓库从远程下载到本地。后面跟上仓库的链接就好。如果你是从 Github 来克隆到本地的话，点绿色按钮的 Clone 就会看到你可以怎么做。你可以直接复制里面的命令然后执行。

• git pull

把远程仓库的内容拉取到本地。和 push 的方向是近乎相反的。如果远程有个修改，你希望同步到本地，那就 git pull 一下吧。

这个命令要注意的点是，不要在本地有修改没存的情况下执行 git pull。如果本地和远程起了冲突，会很麻烦。避免麻烦的最好方式是，先 git pull 之后再做自己的修改。

画个流程图

好累，先聊到这里吧

我们已经介绍了 Git 是什么以及日常会用到的功能。我可以说，除了剩下关于 Git 另一个非常强大的功能：分支的两三个命令，以及一两个我觉得好用的命令以外，剩下的命令都是我很不常用的命令了。剩下的命令几乎只有在我搞砸了什么东西的时候临时从网上搜来救火用的，而保持良好的使用习惯的话真的是很少用到这些麻烦/复杂/难以理解的功能的。

所以，如果你看到了这里，恭喜你已经掌握了 Git 单分支的工作流程了。就是改文件，暂存，提交，推送。而下一章我们会看看 Git 被吹的神乎其神的分支到底是个啥，再解释 Git 中的一些概念。

这里要特别声明的是，这篇文章的比喻借鉴了 HDAlex_John 的 Git 教程系列：给傻子的 Git 教程，讲的相当好。好在我不是傻子，看着也不累，哈哈哈哈。（还是自己写起来比较累）

那么最后，感谢你看到这里，祝你心情愉悦，生活顺遂！~