集中式vs分布式
集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。
集中式版本控制系统最大的毛病就是必须联网才能工作
分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
安装后的配置
1 | $ git config --global user.name "Your Name" |
Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。
git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
文件的增删改查
仓库管理
运行git status命令看看仓库状态git diff查看文件修改记录
文件跟踪
git log命令显示从最近到最远的提交日志
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上
--pretty=oneline参数
Git提供了一个命令git reflog用来记录你的每一次命令
版本管理
假如提交历史记录为下面所示
1 | $ git log --pretty=oneline |
在Git中，用HEAD表示当前版本，也就是最新的提交3628164...882e1e0，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id
我们要把当前版本“latest commit”回退到上一个版本“second commit”，就可以使用git reset命令：
1 | $ git reset --hard HEAD^ |
工作区和暂存区
工作区（Working Directory）：就是你在电脑里能看到的目录
版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
初始化一个Git仓库，使用git init命令。
添加文件到Git仓库，分两步：
- 第一步，使用命令
git add <file>，注意，可反复多次使用，添加多个文件；- 第二步，使用命令
git commit，完成。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的
撤销修改
当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file
当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
已经提交了不合适的修改到版本库时，想要撤销本次提交，使用命令git reset --hard commit_id
删除文件
rm删除文件后，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit，现在，文件就从版本库中被删除了。
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本，使用git checkout -- test.txt，git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
关联远程仓库
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分支管理
分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！
创建合并删除分支
每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上
从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
开始实战：
我们创建dev分支，然后切换到dev分支：
1 | $ git checkout -b dev |
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
1 | $ git branch dev |
然后，用git branch命令查看当前分支：
1 | $ git branch |
git branch命令会列出所有分支，当前分支前面会标一个*号
然后，我们就可以在dev分支上正常提交;
如果dev分支的工作完成，我们就可以切换回master分支：
1 | $ git checkout master |
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，我们把dev分支的工作成果合并到master分支上：
1 | $ git merge dev |
合并完成后，就可以放心地删除dev分支了：
1 | $ git branch -d dev |
丢弃一个没有被合并过的分支，可以通过
git branch -D <name>强行删除。
删除后，查看branch，就只剩下master分支了：
1 | $ git branch |
总结：
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
Bug分支-暂存文件
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作
1 | $ git stash |
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
等到bug修复完毕，继续在dev分支开发时，工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
1 | $ git stash list |
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了
多人协作
多人协作的工作模式通常是这样：
首先，可以试图用
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。
小结：
查看远程库信息，使用
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，如果有冲突，要先处理冲突。
标签管理
发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起
创建标签
在Git中打标签非常简单，首先，切换到需要打标签的分支上，然后，敲命令git tag <name>就可以打一个新标签
1 | $ git tag v1.0 |
可以用命令git tag查看所有标签
1 | $ git tag |
给之前的提交打标签
1 | $ git tag tag_name commit_id |
操作标签
如果标签打错了，也可以删除：
1 | $ git tag -d v0.1 |
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
如果要推送某个标签到远程，使用命令git push origin <tagname>：
1 | $ git push origin v1.0 |
或者，一次性推送全部尚未推送到远程的本地标签：
1 | $ git push origin --tags |
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
1 | $ git tag -d v0.9 |
然后，从远程删除。删除命令也是push，但是格式如下：
1 | $ git push origin :refs/tags/v0.9 |
小结：
命令
git push origin <tagname>可以推送一个本地标签；命令
git push origin --tags可以推送全部未推送过的本地标签；命令
git tag -d <tagname>可以删除一个本地标签；命令
git push origin :refs/tags/<tagname>可以删除一个远程标签。