Git重要命令回顾

摘要

最近正在重新学习Git版本控制系统，以前对Git的了解不太深入，这次基于对张龙老师的Git实战视频课程的学习，对Git又有了进一步的认识。对于Git的深入学习过程，将通过多篇文章来记录。也分享给正在学习的同学。

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

这句话来自于Git的官网，大致意思就是说Git是一个开源免费的分布式的版本控制系统，它可以帮助我们处理不论是小项目还是大项目。最重要的是Git的速度和效率非常优秀。

从官网的介绍我们还可以看到全球知名的互联网公司都在使用Git管理项目，特别是GitHub上，众多的全世界的顶级项目都托管在GitHub上。

• jquery
• spring
• apache

作为程序员来说，如果我们不能很好的掌握Git的操作和使用，我们就不能很好的利用开源世界给我们的帮助，做一些重复造轮子的工作，更何况GitHub上的开源项目都经历了实际生产中的考验。拥有全世界的开发者的pull request。就像张龙老师说的那样。如果你还不会使用Git,那么你就不要写代码了！

其实说了这么多，大多数程序员对Git还是有所了解，日常工作中也会使用sourcetree等图形化工具来协助代码的拉取和推送。知道一些常用的命令：

• git init
• git add
• git commit
• git pull
• git push
• git branch

但是，对Git不了解的同学只是在使用命令，如果一旦出现问题，并不知道如何去解决。所以这也是我们为什么要深入去学习Git原理的部分，让Git真正成为工作的利器，而不是畔脚石。

从现在开始，我将从最基础的命令介绍，一步步触及Git的本质。

创建仓库

在Git中创建一个版本库使用命令
git init
在终端中输入如下命令

mkdir mygit
cd mygit
git init
initialized empty Git repository in /Users/liuhao/Desktop/mygit/.git/

上述命令表示创建一个名为mygit文件夹并进入，使用命令git init,这样这个普通的文件夹就被Git来管理了。从Git的反馈来理解也是这个意思，初始化了一个空了Git仓库指向了我们刚才创建的mygit文件夹。

从提示来看，Git还帮我们创建了一个名为.git隐藏文件夹。从感觉上讲，我们会很自然的想到这个.git文件夹就是Git管理的当前这个仓库的版本信息。既然Git告诉了我们有这个文件夹的存在，那么我们索性进去看看到底有些啥东西。

cd .git
ls -al
total 24
drwxr-xr-x  10 liuhao  staff  340 12 29 11:25 .
drwxr-xr-x   3 liuhao  staff  102 12 29 11:17 ..
-rw-r--r--   1 liuhao  staff   23 12 29 11:17 HEAD
drwxr-xr-x   2 liuhao  staff   68 12 29 11:17 branches
-rw-r--r--   1 liuhao  staff  137 12 29 11:17 config
-rw-r--r--   1 liuhao  staff   73 12 29 11:17 description
drwxr-xr-x  11 liuhao  staff  374 12 29 11:17 hooks
drwxr-xr-x   3 liuhao  staff  102 12 29 11:17 info
drwxr-xr-x   4 liuhao  staff  136 12 29 11:17 objects
drwxr-xr-x   4 liuhao  staff  136 12 29 11:17 refs

这么多，我们先搂两个瞧瞧，其他的目前还不需要了解。

cat HEAD
ref: refs/heads/master
cat config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true

我们可以看到，HEAD文件里面保存的是一个字符串ref: refs/heads/master
对Git稍有了解的同学都知道，在Git中master指的是主分支，在Git中，当我们创建版本库之后提交文件至版本控制系统，就天生活动在master分支，所以HEAD里面的内容也就不难理解。它指的就是当前所处的分支。

对于config文件，内容是一些参数键值对，也就是说这些参数开用户是可以配置的，我们暂且不去管这些参数，我们来学习Git中第二条命令，在终端中执行如下命令：

git config --local user.name 'test'
git config --local user.email 'test@test.com'

通过上诉命令，我们就给当前仓库配置了用户名和用户邮箱。我们再回到config文件中，

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[user]
    name = test
    email = test@test.com

可以清楚的看到config文件中多了三行，我们着重来看最后三行

[user]
    name = test
    email = test@test.com

[user]表示的是用户相关的配置
name表示的是当前使用这个仓库的人，一般在开发中我们写上自己的姓名。
email表示的是这样仓库的人的邮箱，一般在工作项目中，写上自己的企业邮箱。

配置这两个参数的原因我们等会介绍，至少我们现在可以知道这个仓库属于我们自己。

文件状态

说了这么多,现在我们的mygit文件夹中除了.git自动生成的文件。还没有其他文件，我们赶快自己创建一个文件来实验吧，毕竟我们都知道Git给我们最直观的体验，就是用来管理文件的。

cd mygit
echo 'hello 1.txt' > 1.txt
cat 1.txt
hello 1.txt

我们在mygit中创建了一个1.txt并查看其内容为hello 1.txt，至此我们完成了文件的创建，那么我们如何把1.txt提交到版本库中呢？说道这里，我们就要介绍Git中最为重要的三个概念了,它们分别是：

• 工作区
• 暂存区
• 版本库

它们又分别对应三种状态：

• 已修改
• 已暂存
• 已提交

以上三种状态可以用来描述文件的生命周期。当我们新增或修改文件之后，这个文件就处于已修改的状态，你可以选择将其添加到暂存区，使其文件变成已暂存的状态，需要特别注意的是，此时虽然处于暂存区，但是还没有被纳入版本库，要想把文件纳入版本库，必须在暂存区的基础上将其提交到版本库,此时，文件才属于已提交状态。获取文件的状态，我们可以使用git status命令,下面我们来演示这个过程。

git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    1.txt

nothing added to commit but untracked files present (use "git add" to track)

git add 1.txt

当我们输入git status命令之后,Git告诉我们了如下信息：

• 当前处于主分支。
• 还没有被版本控制系统追踪的文件 1.txt。
• 提示我们可以使用git add来暂存1.txt。
• 当前暂存区没有文件，所以没有可以被提交的文件。
• 现在出现了一个文件可以被暂存，以致被提交。

此时输入git add命令，Git并没有反馈，如果没有提示，就说明操作成功，这点Linux的行为。此时我们再次输入git status：

git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   1.txt

此时反馈的内容与git add之前相比，出现了一些变化：

• 目前依然处于主分支。
• 有了一些改变可以被提交。
• 你也可以使用git reset HEAD <file> 将文件从暂存区撤掉，重置为已修改的状态。

我们按照一条路走到底的思路，利用git commit命令将其提交。

git commit -m 'init 1.txt'
master 48a1eb6] 1.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 1.txt

提交文件，使用git commit命令，-m参数为message,填写此次提交信息，需要注意的是，Git推荐也是强制要求我们必须填写message，并且是有用有意义的内容。我们再来摘取提交之后比较重要信息：

• master 48a1eb6] 1.txt

其中的一串数字表示的是commit id,为了区分每一次不同的提交，Git会给我们生产一个不唯一的id。这个commit id非常有用,我们在版本回退的时候会使用它。

此时，我们就走通了一个文件的生命周期的流程。我们使用如下命令来查看当前场景：

git status
On branch master
nothing to commit, working tree clean
git log
commit 48a1eb6b7262d68e28b93d51251c750801b76a24
Author: test <test@test.com>
Date:   Fri Dec 29 13:18:49 2017 +0800

    1.txt

此时，Git首先告诉我们没有可以被提交的内容，也就是说暂存区没有内容，工作区也是干净的，也就是说当前没有修改任何内容。

再往下，我们来认识一个常用的命令git log，它会告诉我们历史提交记录，这里我们看见了比较熟悉的内容，那就是commid id,author,email。这里的commit id是完整的，我们之前看到的是它的前面几位。需要了解的是，commit id非常不唯一，只需要前面几位就能确定是哪一次提交。其它两个信息是我们自己使用git config命令设置的，它会在git log中记录下来。这时我们就大概能体会到之前设置user的好处了。他告诉了Git是谁在提交。

版本回滚

我们知道在Git中,总是有后悔药可以吃的。版本回滚就是一个方面，使用版本回滚，我们可以回到之前的任意一次提交时的状态。
此时我们做如下修改：

vi 1.txt
add 'text'
cat 1.txt
hello 1.txt
text  
git commit -a -f 'second commit'

此时我们重新修改了文件并做了一次提交，文件变成了两行内容。需要注意的是，这里使用了添加和提交合一的命令:
git commit -a -m
使用这条简短命令的前提是，待提交的文件已经被版本控制系统追踪过。
这时我们查看这次提交：

git log
commit 055c5e79b408721a0129d515baa6dd6ad9f8fe27
Author: test <test@test.com>
Date:   Fri Dec 29 14:01:33 2017 +0800

    secode commit

commit 48a1eb6b7262d68e28b93d51251c750801b76a24
Author: test <test@test.com>
Date:   Fri Dec 29 13:18:49 2017 +0800

    1.txt

此时如果我们对当前版本修改的内容不满意，就可以切换到之前的版本，使用命令：

git reset --hard HEAD~n
git reset --hard HEAD^
git reset --hard 48a1e

其中后面两种比较常用。但是推荐使用最后一种方式，给定commit id的一部分，就可以任意的切换到对应的分支。
第一种是将n换成哪一次提交，第二种一个^代表往前推一个版本，在实际使用中，都不太友好。

需要注意的是，有时候我们希望又切回最新的版本，使用git log又看不到较新版本的commit id，可以使用git reflog命令。

git reflog
055c5e7 HEAD@{0}: reset: moving to 055c
4f01813 HEAD@{1}: reset: moving to HEAD~4
055c5e7 HEAD@{2}: commit: secode commit
f52fa35 HEAD@{3}: commit: add
48a1eb6 HEAD@{4}: commit: 1.txt
d2cf225 HEAD@{5}: commit: del
4f01813 HEAD@{6}: commit (initial): init commit

这样会得到每一次版本的commit id，无论当前处于哪个版本。

后悔药

介绍两条可以用来恢复操作的命令

• 将暂存区中的文件回退到已修改状态

  git rm --cached <file>
  

• 将已修改的文件恢复成上次提交后的内容，也就是把上一次提交后的修改丢弃

   git checkout -- <file>
  

需要注意的是要将文件的修改丢弃，该文件必须被版本控制系统追踪过。

分支

以上，我们已经学习了很多命令，这些命令非常基础，需要我们信手拈来。要做到烂熟于心，只有去不断练习,设计场景。
之所以说基础，因为这些命令只需要死记后就能拿来使用，还没有涉及到太多原理性的内容，但是分支却是Git中最重要且核心的概念，其重要性怎么强调也不为过，正是因为有了分支，我们才有了工程化中最佳Git实践。这一切,都来源于分支的支持。

分支中的命令

介绍分支中的命令之前，先将分支涉及的命令做一下概括。

• git branch
• git branch *
• git checkout *
• git checkout -b *
• git merge *
• git merge -d *

这些命令涉及到

• 查看分支
• 创建分支
• 切换分支
• 创建并进入该分支
• 合并分支
• 删除分支

介绍分支，我们重新创建一个仓库来实验,终端中输入如下命令：

mkdir mygit2
touch 1.txt
git add .
git commit -m 'first commit'
git branch
* master
git branch new
git branch
* master
new
git checkout new
master
* new

在介绍以上命令含义时，我们需要明确master分支到底是什么时候被创建的？

master分支的创建时机是当我们在创建版本库之后,完成一次完整的add,commit操作之后才创建的，并不是版本库一创建就天生存在。也就是说，master分支的创建其实也是懒加载。

明白了上述这个问题，我们就很清晰理解我们为什么完成一次提交后，再创建其他分支。
这样，上诉代码的含义就清晰可见了

git add
git commit
// 此时master被创建
git branch 
* master
//此时有且只有一个分支，并且处于master分支
git branch new 
* master
 new
//创建了一个分支名称为new，目前依然处于master分支
git checkout new
master
* new
//切换到new分支

从以上注释也能理解命令的含义。

分支的合并操作

命令 git merge
分支的合并操作决定了多分支的作用。我们在开发中，除了master分支以外，还会自定义创建其他分支，比如开发新功能的分支，解决Bug的分支，测试分支，线上发布分支等等。正因为有分支合并，我们可以把主分支的代码轻松copy一份，也可以在其他分支进行修改后把差异部分合并到master分支。

ls -al
1.txt

可以发现，在new分支上也有了1.txt，这是因为我们创建new分支时，就是基于master分支,也就拥有了和master分支一样的版本库。这时我们增加一行内容：

vi 1.txt
'hello'
git add .
git commit
cat 1.txt
hello

修改文件并提交到new分支的仓库

git checkout master
cat 1.txt
empty
git merge new
Updating c6fdc17..c542424
Fast-forward
 1.txt | 1 +
 1 file changed, 1 insertion(+)
cat 1.txt            
hello

特别需要注意的是，这里出现了一个概念Fast-forward。中文翻译叫快速前进，这个概念比较重要，它的背后隐藏着分支合并的原理，这一部分，内容比较多。下次再进行讲解。

至此我们就完成对new分支修改的内容的合并。