简介：
Git是一个分布式版本管理系统，是为了更好地管理Linux内核开发而创立的。
Git可以在任何时间点，把文档的状态作为更新记录保存起来。因此可以把编辑过的文档复原到以前的状态，也可以显示编辑前后的内容差异。
而且，编辑旧文件后，试图覆盖较新的文件的时候（即上传文件到服务器时），系统会发出警告，因此可以避免在无意中覆盖了他人的编辑内容。
特点：
- Git基本上不删除数据。即使是那些看起来是删除数据的操作，实际上是为了让你更快的撤销删除，而在向系统添加数据。
- Git基本可以撤销所有操作。我鼓励你更多的实验和探索你的想法，因为这就是使用版本控制系统系统的最主要的好处之一。
- 你团队的每一个成员都在他／她的计算机中有各自的副本。本质上这更像是整个版本控制项目中的冗余备份（包括包括整个历史纪录），你捅了大娄子而且还没办法还原这种情况是极其少见的。
操作基础
初始配置
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
注意git config命令的–global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
初始化仓库
$ mkdir learngit
$ cd learngit
$ git init
添加文件到仓库
$ git add readme.txt
提交并添加说明
$ git commit -m "wrote a readme file"
提交多个文件
$ git add file1.txt
$ git add file2.txt
$ git add file3.txt
$ git commit -m "add 3 files."
小结
初始化一个Git仓库，使用git init命令。
添加文件到Git仓库，分两步：
第一步，使用命令git add，注意，可反复多次使用，添加多个文件；
第二步，使用命令git commit，完成。
查看仓库中的文件状态
$ git status
修改并提交文件
git add test.txt
git status
git commit -m "修改了一个bug"
小结
要随时掌握工作区的状态，使用git status命令。
如果git status告诉你有文件被修改过，用git diff可以查看修改内容。
版本回退
历史版本查看
$ git log
回退到上一个版本
git reset --hard [版本号或者HEAD]
HEAD 最近一个提交
HEAD^^ 上一次的 上一次的提交（倒数第三次）
HEAD^^^ 倒数 第四次的 提交
HEAD~0 最近一个提交
HEAD~1 上一次提交
HEAD^2 上一次的 上一次的提交（倒数第三次）
HEAD^3 倒数 第四次的 提交
注意
Git入门书里都会提到放弃最后一次的commit而回复到再上一次commit的指令：
git reset --hard HEAD^
但是这个指令在Windows的命令提示字符cmd.exe里却无法执行，会出现错误:
D:\git-root\test>git reset --hard HEAD^
More?
More?
fatal: ambiguous argument 'HEAD
': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
今天终于弄清楚了：^是cmd.exe的escape字符，属于特殊字符，命令里要用到文字 ^ 时必须用双引号把它夹起来，因此只要如下就可以正确执行：
git reset --hard HEAD"^"
或者：
git reset --hard "HEAD^"
查看git的历史命令操作
git reflog
小结
- HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。 - 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。 - 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
- 工作区（Working Directory）：就是你在电脑里能看到的目录
版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支~master~，以及指向master的一个指针叫HEAD。
git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
查看工作区与版本库的区别
git diff HEAD -- test.txt
将文件恢复到暂存区
git checkout -- test.txt
*git checkout -- file命令中的--很重要，没有--，就变成了“创建一个新分支”的命令*
把暂存区的修改撤销掉（unstage），重新放回工作区
git reset HEAD test.txt
git status查看一下，现在暂存区是干净的，工作区有修改
git checkout – test.txt
小结
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
文件删除
rm test.txt 删除文件
git status 显示删除的文件
git rm test.txt 删掉版本库中的文件
git commit 提交变化
删错了工作区的文件：
git checkout -- test.txt 从版本库恢复回来
小结
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
远程仓库
github/coding/oschina
1.生成SSH Key:
打开git bash 输入ssh-keygen -t rsa -C "youremail@example.com"
输入 cd .ssh
输入 cat id_rsa.pub
2.登陆github，添加ssh key
创建项目并上传到远程仓库
cd parent_dir //进入项目父目录
mkdir gitDemo //创建项目目录 gitDemo
cd gitDemo //进入项目目录
git init //初始化空的 git 仓库
touch README.md
git add README.md //这两行添加简单的 README.md 文件
git commit -m "first commit" //提交时附加的信息
git remote add origin https://coding.net/codingTutorial/gitDemo.git //添加一个名为 origin 的远端（ url 为 git 地址）
git push -u origin master //将该目录下的文件推送到远端（origin）上的 "master" 分支
上传已有项目或更新的项目
cd existing_git_repo //进入已有项目或更新的项目目录
//若该项目目录未建立 git 仓库，则需用 READM.md 初始化 git 仓库，详见“创建新项目上传”
//若有git仓库则直接添加远端仓库上传
//如果目录下有文件没有被追踪（未与远端仓库同步），可以使用“ git add 文件名” 和 “ git commit -m "message" ”，来添加追踪文件
git remote add origin https://coding.net/codingTutorial/gitDemo.git
git push -u origin master //这两行将该目录下的文件推送到远端（origin）上的 "master" 分支
克隆远程仓库
从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。
git clone https://coding.net/coderlt/testGit.git
小结
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！
要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。
Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
分支管理
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
冲突处理
创建一个分支并签出
git checkout -b feature
修改了feature 分支中 test文件
add & commit
签出master分支
修改
add & commit
此时合并分支时会出错 git merge feature
手动解决冲突后，commit
再合并 git merge feature 成功
删除分支： git branch -d feature
查看日志：
$ git log --graph --pretty=oneline --abbrev-commit
小结
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
用git log –graph命令可以看到分支合并图。
分支管理策略
开发时，master分支是主线，用于合并dev分支后发布新版本
测试时在dev分支的基础上工作，从dev上拉分支，然后合并到dev上，再合并到master上发布
*合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并
BUG分支
创建临时分支修复bug,修复后删除bug
保存当前工作区
git stash
例：在dev 中新增了文件t3.txt 并 add 到了存储区
现在有bug issue-101 要修改
先保存工作现场： git stash
查处工作现场： git stash list
签出主分支master,修改bug
git checkout master
git checkout -b issue-101
修改，添加，提交
合并bug分支到master，并删除bug分支
git merge --no-ff -m "merged bug fix 101" issue-101
git branch -d issue-101
回到dev分支上
git checkout dev
恢复工作现场
git stash apply 恢复
git stash drop 删除保存的工作现场
git stash pop 恢复并删除工作现场
恢复并删除指定的工作现场
git stash apply stash@{0}
git stash drop stash@{0}
小结
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
功能分支 Feature
每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支
拉一个featur分支
git checkout -b feature-chktype
修改后添加、提交
如果还没合并到dev, 删除这个feature分支时会失败
可以使用 git branch -D 分支名 强制删除
获取远程仓库信息
git remote
origin
git remote -v 更详细的信息
origin https://coding.net/coderlt/testGit.git (fetch)
origin https://coding.net/coderlt/testGit.git (push)
推送分支
git push origin master
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 branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
错误解决：
Updates were rejected because the tip of your current branch is behind
远程仓库的分支比本地的代码要新所以有冲突，要么把冲突解决掉再提交要么开新分支提交要么就直接
git push –force（多人协作请慎重-。-）。
git pull不行是因为修改了本地，所以远程过来的时候又会有冲突。建议多人协作的时候还是开分支好点。
小结
查看远程库信息，使用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，如果有冲突，要先处理冲突。
标签管理
命令git tag <name>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
git tag -a <tagname> -m "blablabla..."可以指定标签信息；
git tag -s <tagname> -m "blablabla..."可以用PGP签名标签；
命令git tag可以查看所有标签。
用命令git show <tagname>可以看到说明文字
命令git push origin <tagname>可以推送一个本地标签；
命令git push origin --tags可以推送全部未推送过的本地标签；
命令git tag -d <tagname>可以删除一个本地标签；
命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
忽略特殊文件
gitignore
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：
忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
小结
忽略某些文件时，需要编写.gitignore；
.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
设置别名
告诉Git，以后st就表示status
git config --global alias.st status
还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch：
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
以后提交就可以简写成：
$ git ci -m "bala bala bala..."
配置文件
配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中：
git clone
git remote
git fetch
git pull
git push
$ git clone <版本库的网址> <本地目录名>
git clone支持多种协议，除了HTTP(s)以外，还支持SSH、Git、本地文件协议等，下面是一些例子。
$ git clone http[s]://example.com/path/to/repo.git/
$ git clone ssh://example.com/path/to/repo.git/
$ git clone git://example.com/path/to/repo.git/
$ git clone /opt/git/project.git
$ git clone file:///opt/git/project.git
$ git clone ftp[s]://example.com/path/to/repo.git/
$ git clone rsync://example.com/path/to/repo.git/