git常用操作（一篇入门）

咱们按照使用顺序和场景来。

第一步：初始化仓库

初始化仓库要分两种情况：

情况一：初始化本地仓库

就是你本地有一个目录，你想让这个目录成为能被git追踪管理的仓库。

这一步，其实就是让git在这个目录下新建一些配置文件。有了这些文件之后，git就能追踪这个目录下每个文件的变化，方便我们管理。

如果你是windows你直接在对应的目录下右击，用git bash打开。
如果是linux或Mac系统，则通过cd进入到你想其初始化为仓库的目录。

然后执行下面的命令:

git init

这个命令一执行完，你的目录就不一样了，在当前目录下多了一个.git的目录，这个目录是 Git 来跟踪管理版本库的，如果你没有看到 .git 目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看到了，windows你就显示隐藏文件夹。

情况二：克隆已经存在的目录

比如说，别人已经把自己的仓库上传到github或者gitee等平台了。这个仓库已经五脏俱全，已经拥有了.git目录，这个时候，你就不需要初始化了，而是把别人的目录复制下来就行了。这个时候就是用到以下代码：

git clone https://gitee.com/xxxxxx

git clone后面跟着的都是这些网站会提供的地址，直接复制就好了。

必知必会：工作区、暂存区、版本库

git一个很妙的地方，就是让仓库拥有了三种形态。想要搞清楚git的用法，先得知道这三个形态。所以，我先介绍这三种形态，然后再进一步介绍git常用命令。

工作区

你在电脑里硬盘上存储的那个目录，就是git的工作区。这个工作区，就是你直接操作的地方。

暂存区

我们都知道，工作区有一个隐藏目录.git，这个其实已经不算工作区了，它里面记录了文件的前世今生。也就是说，.git目录里记录着文件的各种版本。

而在.git里面，最重要的就是称为stage（或者叫index）的暂存区，还有 Git 为我们自动创建的第一个分支master，以及指向 master 的一个指针叫HEAD。

好好记住这几个概念，因为我们后续各种管理版本的操作，都是在工作区、暂存区、master和HEAD指针之间穿梭。

版本库

版本库你就可以简单理解成最终版本。

第二步：添加并提交到仓库

结合上图来，你在工作区增删或修改了文件，这时候，你觉得是时候保留一次版本了。
这个时候你要做两步操作。
第一步, 先把你的修改通过add命令添加到暂存区。这个操作就跟是“登记”一样，只是把你的版本添加到了暂存区。.git下面会有文件记录你对文件做的修改。
接下来，你要做真正的提交。
这时候你就要用commit命令，把你的修改提交到你想提交的分支上。默认分支就是master。也别管什么是master，反正就是你新建了一个仓库，git就会默认你的操作是在master分支上。这就跟个流水线一样，如果你不指定其它的分支，你的操作都会提交到master分支。

git add .
# . 代表的是所有文件，如果你想添加几个文件，就把文件名写在add后面就行了。
git commit -m "在这里写备注，必须写"

为什么要分两步？

最开始，容易有这样的疑问，为什么不一次性commit得了，还得分两步？
因为add可以多次添加，你可以通过add添加不同的文件，commit就是一锅端了。这样给了我们更多的操作空间。
但是新手，你把这两条命令当成一个用也行，add完紧接着commit。等着熟悉了之后，就有一些场景，让你觉得两者不是说一定得分开来的。

忘记怎么办？

有时忙项目忙忘了，不知道怎么到底提交没提交，那该怎么办？
这时候可以通过git status命令来查看

git status

这里就会给你说得挺清楚，就是已经没有什么要提交的了。

如果你看到返回下面类似的命令：

Changes not staged for commit:
...

我们说过stage在git中表示暂存区，代表就是有文件add了，但没有commit，你在commit一下就好了。

想知道修改了什么？

如果你一下子忘了你修改了什么，可以用git diff命令。
diff是difference的简写，顾名思义，比较两个版本的差别。
git diff后可以加不同的参数比较不同的内容，如果我们什么都不加，就是比较工作区和暂存区文件的差别。
新手，知道这个也就行了，之后的进阶说。
比如，你写下了git diff命令。得到下面的输出结果：

$ git diff
warning: in the working copy of 'a.txt', LF will be replaced by CRLF the next time Git touches it
diff --git a/a.txt b/a.txt
index 35fbd83..d4519ea 100644
--- a/a.txt
+++ b/a.txt
@@ -1,4 +1,3 @@
 aaa
-bbb
 ccc
 ddd

这里前几行是一些文件信息，表示比较了哪两个文件。
从@@开始就代表第一个文件1-4行和第二个文件1-3行不一样。
具体信息给你列出来了。+号代表加了内容，-号代表减了内容。
你就知道修改过程就是删除了“bbb”这一行。

查看log记录

有时你想了解一下到底有多少次提交，每次提交的情况是怎样的。
这时，你可以用git log来查看。

git log

这样你就能看到每次谁提交的，哪天提交的，提交的备注是什么。当然，每一行的最开始，有提供的独特的哈希值。这个也代表着，每次提交都是独特且唯一的。

当然，这里可能有些长，你可以用下面的：

git log --pretty=oneline

结果就比较简洁了。

第三步：Git回退

有时新提交了一个版本，后悔了，想要回到过去的版本。这个时候，就用git reset 命令。
想要了解这个命令，要再重新理解一下HEAD指针。

在 Git 中，用HEAD表示当前版本，也就是最新的提交。
默认情况下，HEAD指针指向了master分支的最后一次提交。

git reset 命令就是重新把HEAD指针移到之前的分支上。
怎么找到这个分支呢，上面讲git log的时候说了，每次提交都会生成一个哈希值，这个哈希值就是每次提交的代号。
你可以通过代码回到哈希值对应的版本处。

git reset --hard e66666a(哈希值随便写的)

我们说过HEAD指针指向最新的提交，这代表着哈希值为e66666a的提交成为了最新版本，这也代表了e6666a之后的提交就没有了。

当然，最常用的操作就是倒退一步或两步，这个时候去查找哈希值显得有点麻烦了。
我们可以用HEAD^代表上一个版本，HEAD^^代表上上个版本。当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

git reset HEAD^

第四步：重置

大家都说，世上没有后悔药吃。但是在git领域，就是有后悔药。
当你用git reset回退到一个版本后，这个版本就成最新的了，这代表着这个版本之后提交的版本都没有了。
要想回到这些版本怎么办呢，其实主要是找到它们的哈希值。
这个时候，就用新命令。

git reflog

git reflog用来记录你的每一次命令。如下：

这里记录了每个操作的哈希值。
你可以通过

git reset --hard  哈希值

回到对应的版本就好了。

第五步：放弃工作区

当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file

请记住，git checkout 是一个危险的命令。 你对那个文件在本地的任何修改都会消失。Git 会用最近提交的版本覆盖掉它。 除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。

说白了，就是用暂存区的内容代替工作区的内容。是提交的反向操作。

总结

在这里我们看到了自己一个人操作版本库常用的操作。但是需要涉及到多人 合作的时候应该怎么办？下个文章见。