@TOC
# Git
廖雪峰Git教程网站
Git简介
Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统
集中式和分布式版本控制系统有什么区别呢？
集中式版本控制系统： 版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。
集中式版本控制系统最大的毛病： 就是 必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。
首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
安装Git
安装完成后，还需要最后一步设置，在命令行输入：1
2$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
创建版本库
首先选择一个合适的地方（win系统为例）
进入D盘，然后进入D盘的名为Git的文件夹：
$ cd D:
创建一个空目录：1
2
3
4$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
第二步，通过git init命令把这个目录变成Git可以管理的仓库：
1 | $ git init |
把文件添加到版本库
所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。
而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
现在我们编写一个readme.txt文件，内容如下：1
2Git is a version control system.
Git is free software.
一定要放到learngit目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
把一个文件放到Git仓库只需要两步。
第一步，用命令git add告诉Git，把文件添加到仓库：1
$ git add readme.txt
第二步，用命令git commit告诉Git，把文件提交到仓库：1
2
3
4$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
1 file changed, 2 insertions(+)
create mode 100644 readme.txt
简单解释一下
git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。
因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：1
2
3$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."
时光机穿梭
修改一下readme.txt文件。
运行git status命令看看结果：1
2
3
4
5
6
7
8
9$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
git status命令可以掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
git diff 可以查看上次是如何修改文件的具体内容。
知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步：
第一步git add:1
$ git add readme.txt
执行第二步git commit之前，我们再运行git status看看当前仓库的状态：1
2
3
4
5
6$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: readme.txt
git status告诉我们，将要被提交的修改包括readme.txt
下一步，就可以放心地提交了：1
2
3$ git commit -m "add distributed"
[master e475afc] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)
此时，可用git status再次查看仓库状态：1
2
3$ git status
On branch master
nothing to commit, working tree clean
Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。
要随时掌握工作区的状态，使用
git status命令。
如果git status告诉你有文件被修改过，用git diff可以查看修改内容。
版本回退
每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复。
版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看：
git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：1
2
3
4$ git log --pretty=oneline
d50eaf48d9846be0e11b46cac57cee7c11c59fd9 (HEAD -> master) append GPL
fdaa14c4e77cf920f438e1fe6133ecb782a72843 add distributed
d0e860422fe442aa574b34a3dff10a22955300dd wrote a readme file
在Git中，用HEAD表示当前版本，也就是最新的提交d50eaf……（注意我的提交ID和你的肯定不一样），上一个版本就是 HEAD^ ，上上一个版本就是 HEAD^ ^ ，当然往上100个版本写100个^ 比较容易数不过来，所以写成HEAD~100。
把当前版本append GPL回退到上一个版本add distributed，就可以使用git reset命令：1
2$ git reset --hard HEAD^
HEAD is now at fdaa14c add distributed
看看readme.txt的内容是不是版本add distributed：
$ cat readme.txt
Git is a distributed version control system.
Git is free software.
此时，若想再回到最新版本 append GPL , 则需要从之前打印的日志中找出最新日志的ID序号，找到那个append GPL的commit id是d50ea，于是就可以指定回到未来的某个版本：1
2$ git reset --hard d50ea
HEAD is now at d50eaf4 append GPL
如果中途关掉了电脑，找不到之前的日志，Git提供了一个命令git reflog用来记录你的每一次命令：1
2
3
4
5
6$ git reflog
d50eaf4 (HEAD -> master) HEAD@{0}: reset: moving to d50ea
fdaa14c HEAD@{1}: reset: moving to HEAD^
d50eaf4 (HEAD -> master) HEAD@{2}: commit: append GPL
fdaa14c HEAD@{3}: commit: add distributed
d0e8604 HEAD@{4}: commit (initial): wrote a readme file
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令
git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
工作区（Working Directory）：就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区。
版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；（用git status查看）
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
管理修改
为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：
第一次修改 ->
git add-> 第二次修改 ->git add->git commit
提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别：
撤销修改
git checkout -- file可以丢弃工作区的修改：
一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt 已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。
如果修改了文件以后，并且已经git add到暂存区了
用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步:第一步用命令git reset HEAD <file>，就回到了场景1；第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
删除文件
一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了
$ rm test.txt
这时候Git的工作区和版本库就不一致了，可以用git status查看是哪些文件被删除了。
现在有两种选择：
- 确定删除：就用命令
git rm删掉，并且git commit： - 删错了，要恢复：根据Git的提示，用
git checkout -- <file>..."一键恢复。
远程仓库
完全可以自己搭建一台运行Git的服务器，不过现阶段，为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫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"
把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可.
一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：
点“Add Key”，你就应该看到已经添加的Key：
为什么GitHub需要SSH Key呢？
因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
如果你不想让别人看到Git库，有两个办法：
一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。
添加远程——（先有本地库，后有远程库）
首先，登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库：
在Repository name填入learngit，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：
目前，在GitHub上的这个learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库；也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
我们根据GitHub的提示，在本地的learngit仓库下运行命令：
$ git remote add origin http/SSH
##注释：HTTPS和SSH网站会自动给出。
https://github.com/server-name/repository-name.git
git@github.com:server-name/repository-name.git
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
下一步，就可以把本地库的所有内容推送到远程库上：
$ git push -u origin master
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub
要关联一个远程库，使用命令
git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
从远程库克隆——（先创建远程库，从远程库克隆）
从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。
首先，登陆GitHub，创建一个新的仓库，名字叫gitskills：
我们勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件：
下一步是用命令git clone克隆一个本地库：1
2
3
4
5$ git clone git@github.com:michaelliao/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.
进入gitskills目录看看，已经有README.md文件了
$ cd gitskills
$ ls
README.md
要克隆一个仓库，首先必须知道仓库的地址，然后使用
git clone命令克隆。
Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
分支管理
创建与合并分支
我们把dev分支的工作成果合并到master分支上：
1 | $ git merge dev |
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
解决冲突
当合并发生冲突时，查看测试文件readme.txt的内容：1
2
3
4
5
6
7
8
9
10$ cat readme.txt
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 of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，这时打开文件编辑器，会发现文件已经被修改为上述内容。手动修改后保存。
用带参数的git log也可以看到分支的合并情况：1
$ git log --graph --pretty=oneline --abbrev-commit
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。
分支管理策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
可以看到，不使用Fast forward模式，merge后就像这样：
Bug分支
Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：1
2$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
1 | $ git stash list |
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
- 一是用
git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除； - 另一种方式是用
git stash pop，恢复的同时把stash内容也删了：再用git stash list查看，就看不到任何stash内容了：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
Feature分支
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
要查看远程库的信息，用git remote：1
2$ git remote
origin
用git remote -v显示更详细的信息：1
2
3$ git remote -v
origin https://github.com/AlexGoke/Code-Practice-Python.git (fetch)
origin https://github.com/AlexGoke/Code-Practice-Python.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：1
$ git push origin master
如果要推送其他分支，比如dev，就改成：1
$ git push origin dev
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
- master分支是主分支，因此要时刻与远程同步；
- dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
- bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
- feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支
因此，多人协作的工作模式通常是这样：
- 首先，可以试图用
git push origin <branch-name>推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin <branch-name>推送就能成功！ - 如果
git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
查看远程库信息，使用
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，如果有冲突，要先处理冲突。
Rebase
rebase操作可以把本地未push的分叉提交历史整理成直线；
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
标签管理
创建标签
默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
方法是找到历史提交的commit id，然后打上就可以了：
1 | $ git log --pretty=oneline --abbrev-commit |
比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令：
$ git tag v0.9 f52c633
注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
$ git tag -a v0.1 -m "version 0.1 released" 1094adb
命令
git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
命令git tag可以查看所有标签。
操作标签
命令
git push origin <tagname>可以推送一个本地标签；
命令git push origin --tags可以推送全部未推送过的本地标签；
命令git tag -d <tagname>可以删除一个本地标签；
命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
使用Github
在GitHub上，可以任意Fork开源仓库；
自己拥有Fork后的仓库的读写权限；
可以推送pull request给官方仓库来贡献代码。
