Git学习笔记

此篇笔记是学习参考廖雪峰老师的Git教程，附上学习网址：https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

Git是目前世界上最先进的分布式版本控制系统（没有之一）。

先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。

那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

1 安装Git

针对windows端，下载地址：https://git-scm.com/download/win

选择想要存放的地址，默认安装即可。安装成功后第一件事就是要让它知道自己的主人是谁，因为每一个Git的提交都会使用到这些信息，一旦确定不可更改。

安装完后进入安装目录，在命令行模式下输入以下命令：

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

可使用如下代码查看自己的注册成功与否：

git config --list

2 工作区、暂存区、版本库

Git的核心框架为：工作区域、暂存区域和Git仓库

在初始化git版本库之后会生成一个隐藏的文件 .git ，可以将该文件理解为git的版本库 repository，而我们自己建立的项目文件夹即工作区 working directory，在.git 文件夹里面还有很多文件，其中有一个index 文件就是暂存区也可以叫做 stage，git还为我们自动生成了一个分支master以及指向该分支的指针head，如下图所示：

从图中可以看出来respository包括分支master和stage, working diretory 可以理解为我们打开开发环境如eclipse，里面的内容即工作区的内容，在工作区里面有的代码以及配置文件等我们需要提交到版本库里面，最终是到了分支master上面，暂存区只是一个临时保存修改文件的地方。

工作区域（Working Directory）：就是你平时存放项目代码的地方

暂存区域（Stage）：用于临时存放你的改动，事实上它只是一个文件，保存即将提交的文件列表信息。

Git仓库（Repository）：就是安全存放数据的位置，这里有你提交的所有版本的数据，其中HEAD指向最新放入仓库的版本。

Git的工作流程如下：
（1）在工作目录中添加、修改文件；

（2）将需要进行版本管理的文件放入暂存区域；

（3）将暂存区域的文件提交到Git仓库。

因此，Git管理的文件有三种状态：已修改（modified）、已暂存（staged）和已提交（committed），依次对应上面的每一个流程。有时你并不想把工作目录中的所有新功能都提交到最新版本，你就可以先添加一些本次需要提交的文件到暂存区，然后从暂存区中提交它们，所以暂存区又称“索引”。

3 创建版本库并添加文件

选择一个合适的地方，创建一个空目录。如下通过git init命令把这个目录变成Git可以管理的仓库：

当前目录下会多一个.git的目录，是Git用来跟踪管理版本库的，不要轻易改动，否则将会破坏Git仓库，该目录默认是隐藏的。

所有的版本控制系统其实只能跟踪文本文件的改动，如果要真正使用版本控制系统，就要以纯文本方式编写文件。建议使用Notepad++代替记事本进行编辑，记得把Notepad++的默认编码设置为UTF-8 without BOM即可。在MyGit文件夹下新建一个readme.md文件，内容如下：

Git is a version control system.
Git is free software.

接着我们把该文件放到Git仓库：
（1）用命令git add告诉Git，把文件添加到仓库：

git add readme.md

（2）用命令git commit告诉Git，把文件提交到仓库：

git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。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."

4 查看工作状态和历史提交

要随时掌握工作区的状态，使用git status命令。
如果git status告诉你有文件被修改过，用git diff可以查看修改内容。

将readme.md文件修改如下：

Git is a distributed version control system.
Git is free software.

如下所示，git status告诉我们readme.md被修改了，但还没准备提交的修改，git diff告诉我们被修改的内容，显示的格式是Unix通用的diff格式。

知道了作了什么修改后，可提交修改，同3所示。

5 版本回退

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

6 管理修改

Git管理的是添加到暂存区里面的修改，而非文件。包括增删改等等都算是可以跟踪的文件变动，也可以说git只管理我们变动的部分变动的我们才往暂存区提交，这也是git比其他版本系统设计优秀的一点。

举例说明，在readme.md中加入一行：

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

通过add添加后，再修改最后一句为：

Git tracks changes of files.

通过commit提交后发现第二次的修改没有被提交，原因是因为Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

每次修改，如果不add到暂存区，那就不会加入到commit中。

7 撤销修改

当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file；
当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

8 删除文件

新建一个test.txt文件到Git并提交，如果直接在文件管理器中删除了该文件，或者使用rm/del命令删除，此时删除的是工作区的文件。Git知道你删除了文件，因此，工作区和版本库就不一致了，可通过git status查看哪些文件被删除了。

此时版本库中还存在该文件，则使用git rm命令删除，并且通过git commit提交。

rm只是删除了你想删除的文件，是在工作区操作的，还没有把这个修改放到暂存区，然后你用“git rm”命令，就是把工作区删除文件的操作放到了暂存区的。

但是如果你直接用“git rm”命令，就相当于直接完成了“rm”和“git rm”这两个命令，前一个命令被自动执行了。这时候你再“git status”一下，你就会发现，你已经把删除工作区文件这个操作放到了暂存区，只等你提交到版本库里去了。注意看以上的代码的第四行“ (use "git add/rm <file>..." to update what will be committed)”。当你“rm”操作以后，再进行“git rm”,其实和“git add”的作用是等同的。

如果在工作区中误删除了文件，版本库仍然存在该文件，所以可以使用git checkout版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

git checkout -- test.txt

9 远程仓库

Github网站提供Git仓库托管服务，只要注册一个Github账号，就可以免费获得Git远程仓库。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

第2步：登陆GitHub，打开“settings”，“SSH Keys”页面：

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容，点“Add Key”，你就应该看到已经添加的Key。

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。

如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。

9.1 添加远程库

如何使本地的Git仓库和Github中的Git仓库远程同步？

首先，登录Github，右上角点击New repository，创建一个新仓库，填入仓库名称MyGit，其他保持默认设置即可。

在本地的MyGit仓库的命令行下运行如下命令：

git remote add origin git@github.com:Github账户名/MyGit.git

添加后，远程库的名字就是origin，这是Git的默认叫法，也可以更改。

下一步就可把本地库的所有内容推送到远程库上：

git push -u origin master

第一次推送时会出现警告，根据提示输入yes回车即可。

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。第一次推送后，只要本地作了提交，就可以通过命令：

git push origin master

把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！

9.2 从远程库克隆

上次我们讲了先有本地库，后有远程库的时候，如何关联远程库。现在，假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。首先，登陆GitHub，创建一个新的仓库，名字叫gitskills。勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件。

现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

在Git Bash中使用git clone克隆一个本地库，或者在命令行模式下选择你要放置的文件夹，输入相同的命令：

Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。

10 分支管理

10.1 创建与合并分支

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

创建+切换分支：git checkout -b <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

发现上述的命令即可在命令行的模式下进行，也可以在Git Bash下操作，以下操作在Git Bash下运行。

切换目录，首先创建dev，然后切换到dev：

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

git branch命令会列出所有分支，当前分支前面会标一个*号。然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：

Creating a new branch is quick.

add并commit提交，dev分支的工作完成，可切换回master分支：

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

现在，我们把dev分支的工作成果合并到master分支上：

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

合并完成后，就可以放心地删除dev分支了：

10.2 解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

用git log --graph命令可以看到分支合并图。

10.3 分支管理策略

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

10.4 Bug分支

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。

10.5 Feature分支

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

10.6 多人协作

查看远程库信息，使用git remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

11 标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

11.1 创建标签

命令git tag <name>用于新建一个标签，默认为HEAD，也可以指定一个commit id（使用git log --pretty=oneline --abbrev-commit查看历史提交的commit id，使用git tag <tagname> commit id即可打标签）；
git tag -a <tagname> -m "blablabla..."可以指定标签信息，用命令git show <tagname>可以看到说明文字；
git tag -s <tagname> -m "blablabla..."可以用PGP签名标签；
命令git tag可以查看所有标签。