Git的一些基本操作
1.设置用户信息
设置用户名和邮箱，这样，在每次操作的时候知道是哪个用户做的操作。
[root@CentOS1 ~]# git config --global user.name "lizexiong" [root@CentOS1 ~]# git config --global user.email "lizexiong@huawei.com"
查询设置的基本信息
[root@CentOS1 ~]# git config --list user.name=lizexiong user.email=lizexiong@huawei.com
2.设置Git颜色
在Git查询的时候，Git默认是没有颜色显示的，现在开启颜色显示。
[root@CentOS1 ~]# git config --global color.ui true [root@CentOS1 ~]# git config --list user.name=lizexiong user.email=lizexiong@huawei.com color.ui=true
3.创建版本库
什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
创建版本库目录
通过git init命令把这个目录变成Git可以管理的仓库
瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。
4.把文件添加到版本库
首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
使用Windows的童鞋要特别注意：
千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：
现在我们编写一个readme.txt文件，内容如下：
一定要放到git目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
第一步，用命令git add告诉Git，把文件添加到仓库：
没有任何显示就是执行成功。
[root@CentOS1 git]# git add readme.txt
第二步，这里可以使用git status 来查看新增的文件:
第三步，用命令git commit告诉Git，把文件提交到仓库：
现在在使用git status查看，文件已经被提交到仓库了
命令详解：
简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。
嫌麻烦不想输入-m "xxx"行不行？确实有办法可以这么干，但是强烈不建议你这么干，因为输入说明对自己对别人阅读都很重要。实在不想输入说明的童鞋请自行Google，我不告诉你这个参数。
git commit命令执行成功后会告诉你，1个文件被改动（我们新添加的readme.txt文件），插入了两行内容（readme.txt有两行内容）。
为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：
$ git add file1.txt $ git add file2.txt file3.txt $ git commit -m "add 3 files."
本章小结:
添加文件到Git仓库，分两步：
第一步，使用命令git add <file>，注意，可反复多次使用，添加多个文件；
第二步，使用命令git commit，完成。
5.文件修改之对比及查看
上一步已经成功地添加并提交了一个readme.txt文件，现在，是时候继续工作了，于是，我们继续修改readme.txt文件，改成如下内容：
现在，运行git status命令看看结果：
git status命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
虽然Git告诉我们readme.txt被修改了，可以用git diff来查看文件哪里修改了。
现在重新提交到仓库，先添加要提交的文件，查看以下状态。
现在git commit提交查看状态
当然，还可以查看文件变化的log。
6.版本回退
这里为了演示，所以在修改一次文件来对比。
像上述步骤一样,不断对文件进行修改，不断提交到版本库里面，就相当于玩游戏的存档。经过上述的提交，现在整个文件已经经过了3次提交，2次修改。
当然，个人不可能记住自己修改了多少次，所以git log已经全部记录了，这就是-m备注的好处。
git log命令显示从最近到最远的提交日志，我们可以看到3次提交。
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：
这里可以看到，看到的一大串类似719a775……104fe0的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的commit id和我的肯定不一样，以你自己的为准。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。
现在可以看到文件的一些信息，开始版本回退。
- 回退方式一
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交719a775……104fe0（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
- 回退方式二
回退方式一讲解了直接使用HEAD回退，回退之后查看git log，已经没有第三版本的log记录了。
而且用回退方式一，如果有很多版本，人为不好记录，而且，当版本回退到之前的版本后，没有版本log记录了，所以这里使用第二种方式来回退，也就是版本号的方式来回退。
查看文件的版本号。
本章小结
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
7.工作区和暂存区
Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。
工作区（Working Directory）
就是你在电脑里能看到的目录，比如我的git文件夹就是一个工作区：
版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
俗话说，实践出真知。现在，我们再练习一遍，先对readme.txt做个修改，比如加上一行内容：
然后，在工作区新增一个LICENSE文本文件（内容随便写）。
先用git status查看一下状态：
Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。
现在，使用两次命令git add，把readme.txt和LICENSE都添加后，用git status再查看一下：
现在，暂存区的状态就变成这样了：
所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：
现在版本库变成了这样，暂存区就没有任何内容了
8.管理修改
本次管理修改演示的是以下步骤:
第一次修改 -> git add -> 第二次修改 -> git commit
现在查看git status，发现，第二次修改没有提交。
前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别：
如果第二次修改想要提交，只能再次把文件放入暂存区。然后在提交
9.撤销修改
自然，自己也有突然觉得写错的时候，比如，在文件最后新增了一行。
这里因为还没有添加以及提交，手动删除这个错误即可，但是，如果用git status来查看一下。Git会告诉你，git checkout -- file可以丢弃工作区的修改：
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。
git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令。
当然，这里还有第二种可能，不但写错了一些文件，还提交到暂存区了,庆幸的是,在commit之前，发现了这个错误，用git status查看以下，修改只是提交到了暂存区，还没有提交。
Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区：
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
再用git status查看一下，现在暂存区是干净的，工作区有修改：
然后在次丢弃工作区的修改
本章小结:
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
10.删除文件
在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：
一般情况下，通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：
这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
现在有两种情况选择.
- 一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit；
现在，文件就从版本库中被删除了。
- 另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本；
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
本章小结：
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
