Git 详解

CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？

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

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

分布式版本控制系统：首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已

创建版本库

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”

1> 首先进入到合适的目录中，通过 git init 指令把该目录变成 Git 可以管理的仓库

此时就会在目标目录下多一个 .git 目录，，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏

2> 添加文件

     (1) 用命令 git add 告诉Git，把文件添加到仓库

     (2) 用命令 git commit 告诉Git，把文件提交到仓库

3> 查看库状态

     (1)  git status 命令可以让我们时刻掌握仓库当前的状态，哪些文件被修改，删除等

     (2) git diff 查看文件的difference

重新提交，没有冲突后，查看状态，就会显示

4> 版本回退

     (1) git log 查看历史版本

加上 --pretty=oneline 仅显示版本号

查看具体哪一个文件

     (2) Git必须知道当前版本是哪个版本，在Git中，用 HEAD 表示当前版本，也就是最新的提交

     (3) 使用 git reset 指令回到以前版本

     (4) 通过 git log 可以看到，回到上一个版本后就缺少一个版本

     (5) 只要上面的命令行窗口还没有被关掉，再次通过 git reset 回到指定版本

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向原来版本，append GPL：

改为指向add distributed：

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪

     (6) git reflog用来记录你的每一次命令

4> 工作区和暂存区

工作区（Working Directory）：就是你在电脑里能看到的目录（就是含 .git 文件夹的目录，除 .git 的其它文件）

版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD

把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用 git add 把文件添加进去，实际上就是把文件修改添加到暂存区

第二步是用 git commit 提交更改，实际上就是把暂存区的所有内容提交到当前分支

创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改

将 readme.txt 通过 git add 添加，暂存区的状态就变成这样

所以，git add 命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行 git commit 就可以一次性把暂存区的所有修改提交到分支，通过 git commit 现在版本库变成了这样，暂存区就没有任何内容

5> 为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件

什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改

第一次修改 -> git add -> 第二次修改 -> git commit

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

第一次修改 -> git add -> 第二次修改 -> git commit

你看，我们前面讲了，Git管理的是修改，当你用 git add 命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit 只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交

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

6> 撤销修改

命令 git checkout -- readme.txt 意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

      一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态

      一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态

总之，就是让这个文件回到最近一次 git commit 或 git add 时的状态

git checkout -- file 命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令

当缓存区为空，修改文件，此时使用 get checkout 指令，将返回到最近一次 git commit 状态

将文件 git add 到缓存区，此时修改，使用 get checkout 指令，将返回到最近一次 git add状态

7> 删除文件

通常直接在文件管理器中把没用的文件删了，或者用 rm 命令删，此时使用 git status 将会显示文件删除

确认要删除文件就使用 git rm 删掉，并用 git commit 提交到分支

git checkout 把误删的文件恢复到最新版本

8> 远程仓库

由于你的本地 Git仓库 和 GitHub仓库 之间的传输是通过SSH加密的，所以，需要一点设置：

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

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

  (2) 登陆GitHub，打开“Account settings”

“SSH Keys”页面，然后，点“New SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容（使用文本编辑器打开）：

点“Add SSH Key”，进入到密码输入页面重新输入密码，就可以看到已经添加的Key：

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了

9> 添加远程库

  (1) 登陆GitHub，然后，在右上角找到 Repositoyies 界面，再点击 New 按钮，创建一个新的仓库：

输入新库的名称，填上描述信息，再点击 Create repository 按钮，就创建一个库

  (2) GitHub 可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库

在本地的learngit仓库下运行命令，来关联GitHub：

  (3) 使用 $ git push -u origin master 指令将代码推送到GitHub服务器，其中 master 是当前默认分支

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。推送成功后，可以立刻在GitHub页面中看到远程库的内容和 Git Bash 控制台所在目录的文件一模一样

从现在起，只要本地作了提交，就可以通过命令：$ git push origin master

10> 从远程库克隆

通过 git clone 指令，将远端代码导入到本地

     2> GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https

11> 分支管理，创建与合并分支

每次提交，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分支：

  (1) 使用 git checkout 指令创建dev分支，然后切换到dev分支：

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

然后，使用 git branch 指令，查看当前分支：

此时就可以在 dev 分支上提交，在分支上完成工作后，通过 git checkout 就可以切回到 master分支

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

现在通过 git merge 把dev分支的工作成果合并到master分支上：

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快

合并完成后，就可以放心地删除dev分支了，通过 git branch -d 指令实现：

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

分支管理常用指令：

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

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

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

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

12> 解决冲突

模拟一个场景，在 dev 分支修改 b.txt 并提交，转到 mater 分支同样修改 b.txt 并提交，此时合并两个分支将会出现冲突错误提示

master分支和feature1分支各自都分别有新的提交，变成了这样：

直接打开文件，可查看到冲突：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，修改完文件解决冲突后：

此时，重新提交代码：

现在，master分支和 dev 分支变成了下图所示：

使用 git log --graph --pretty=oneline --abbrev-commit 查看解决情况：

最后注意删除 dev 分支

13> 分支管理策略

在实际开发中，我们应该按照几个基本原则进行分支管理：首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以，团队合作的分支看起来就像这样：

Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并，使用指令：

14> Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交。并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？幸好，Git还提供了一个 git stash 指令功能，可以把当前工作现场“储藏”起来，转到要修改的分支，等到分支Bug解决以后恢复现场后继续工作，此时使用 git stash list 来查看现场：

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

<1> 用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除

<2> 用git stash pop，恢复的同时把stash内容也删了

在用 stash list 就查看不到任何 stash内容

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

15> 开发一个新feature，最好新建一个分支；如果要丢弃一个没有被合并过的分支，可以通过 git branch -D <branch_name> 强行删除

16> 多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。要查看远程库的信息，用 git remote 指令，也可使用 git remote -v 显示更详细的信息：

  (1) 推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支（可以是master或是其他分支）推送到远程库对应的远程分支上，使用指令 git push origin <branch_name>：

并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

 <1> master分支是主分支，因此要时刻与远程同步

 <2> dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步

 <3> bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug

 <4> feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定

  (2) 抓取分支

从远程库clone时，默认情况下，只能看到本地的 master分支

创建远程仓库分支，直接在分支管理界面：

使用 git push 指令将代码提交到远程仓库，这样就把分支代码提交到远程仓库：

远程分支和本地分支需要区分，所以，在从服务器上拉取特定分支的时候，需要指定本地分支名字，使用指令：

指定本地dev分支与远程origin/dev分支的链接，再使用 git pull 指令就可以从远端仓库中拉去存在冲突的代码

合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

多人协作的工作模式通常是这样：

    > 首先，可以试图用 git push origin branch-name 推送自己的修改

    > 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并

    > 如果合并有冲突，则解决冲突，并在本地提交

    > 没有冲突或者解决掉冲突后，再用 git push origin branch-name 推送就能成功

如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令 git branch --set-upstream branch-name origin/branch-name

17> 标签管理

发布一个版本时，我们通常先在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。Git 的标签虽然是版本库的快照，但其实它就是指向某个 commit 的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的

  (1) 创建标签

切换到要打标签的分支上，然后使用 git tag <name> 就可以打一个新标签：

  (2) 使用 git tag 查看所有分支

  (3) 默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？方法是找到历史提交的commit id，然后打上就可以了，使用指令 git tag <tag_name> <commit_id>：

  (4) 查看标签信息，使用指令 git show <tagname>：

  (5) 还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

  (6) 使用 git tag -d <tag_name> 指令删除标签：

  (7) 创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。如果要推送某个标签到远程，使用命令

在 GitHub 中，此时就可以查看到提交的标签

  (8) 删除远端标签，先从本地删除标签，然后，从远程删除。删除命令也是push，指令是：

18> 忽略特殊文件

在Git工作区的根目录下创建一个特殊的 .gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件，使用指令

touch .gitignore 就会在根目录下生成了一个“.gitignore”文件

每一个忽略文件占一行，如下：

忽略文件的原则是：

    >忽略操作系统自动生成的文件，比如缩略图等

    >忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件

    >忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件