廖雪峰git教程
一、SVN是集中式的版本控制系统， 版本库是集中存放在中央服务器的 。干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。
缺点：必须联网才能工作
二、Git是分布式版本控制系统，没有“中央服务器”，每个人的电脑上都是一个完整的版本库。假如你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此， 分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
三、 注意 ：
从Git官网直接下载安装程序，然后按默认选项安装即可。安装完成后，在开始菜单里找到
“Git”->“Git Bash”
，在命令行输入：
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
# --global参数表示你这台机器上所有的Git仓库都会使用这个配置
因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。
repository可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来。
# 1. 创建空文件夹并进入。
$ mkdir learngit
$ cd learngit
$ pwd # 显示当前目录
/Users/michael/learngit
# 2. 通过git init命令把这个目录变成Git可以管理的仓库
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
也可以让git来管理已有的文件夹，此时不用创建空文件夹，直接cd到要管理的文件夹，然后执行执行
git init即可
如此就创建好了repository，你会发现当前目录learngit下多了一个
.git
的文件夹，这个文件夹是Git来跟踪管理版本库的。
在当前目录learngit下创建一个readme.txt，内容如下：
Git is a version control system.
Git is free software.
接下来我们将readme.txt添加到repository：
git add
告诉Git，把文件添加到仓库：
$ git add readme.txt
，执行命令后没有任何显示即为成功。
git commit
告诉Git，把文件提交到仓库：
$ 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
# -m后面输入的是本次提交的说明
commit可以一次提交很多文件，所以你可以多次add不同的文件做一次提交
git add readme.txt
，得到错误：
fatal: not a git repository (or any of the parent directories)。
git add readme.txt
，得到错误
fatal: pathspec 'readme.txt' did not match any files。
将readme.txt文件改成如下内容：
Git is a distributed version control system.
Git is free software.
运行
git status
命令查看仓库当前的状态：
$ git status
On branch master
Changes not staged for commit:# 文件被修改了但还未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 diff
查看修改的内容
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@ # 改变的两行进行比对：
-Git is a version control system.
+Git is a distributed version control system.
Git is free software.
将修改后的文件提交到repository和提交新文件是一样的
$ git add readme.txt
在执行第二步
git commit
之前，我们先运行
git status
看看当前仓库的状态：
$ git status
On branch master
Changes to be committed: # 将要被提交的修改包括readme.txt
(use "git reset HEAD <file>..." to unstage)
modified: readme.txt
$ git commit -m "add distributed"
[master e475afc] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)
提交后，我们再用
git status
命令看看仓库的当前状态：
$ git status
On branch master
nothing to commit, working tree clean
# 没有需要提交的修改，而且，工作目录是干净
修改readme.txt文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
然后添加到仓库：
$ git add readme.txt
$ git commit -m "append GPL"
[master 1094adb] append GPL
1 file changed, 1 insertion(+), 1 deletion(-)
当你觉得文件修改到一定程度的时候，就可以commit一下。一旦你把文件改乱了，或者误删了文件，可以从commit中恢复。使用
git log
命令查看readme.txt有哪些版本被提交到Git仓库里了（会按照从最近到最远的提交日志显示）：
$ git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:06:15 2018 +0800
append GPL
commit e475afc93c209a690c39c13a46716e8fa000c366
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:03:36 2018 +0800
add distributed
commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 20:59:18 2018 +0800
wrote a readme file
如果嫌输出信息太多，可以试试加上
--pretty=oneline参数：
$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
# 前面的那一串是commit id
现在打算把readme.txt回退到上一个版本，也就是
add distributed
的那个版本，使用
git reset
命令回退：
$ git reset --hard HEAD^
HEAD is now at e475afc add distributed
在Git中，用HEAD表示当前版本，也就是最新的提交1094adb…，上一个版本就是
HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100
看看readme.txt的内容是不是版本add distributed的内容：
$ cat readme.txt
Git is a distributed version control system.
Git is free software.
果然被还原了，使用
git log
再看看现在版本库的状态
$ git log
commit e475afc93c209a690c39c13a46716e8fa000c366 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:03:36 2018 +0800
add distributed
commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 20:59:18 2018 +0800
wrote a readme file
最新的那个版本append GPL已经看不到了！好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，怎么办？办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以找到那个append GPL的commit id是1094adb…，于是就可以指定回到未来的某个版本：
$ git reset --hard 1094a
HEAD is now at 83b0afe append GPL
版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
再看看readme.txt的内容：
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
果然又恢复了。
Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：
改为指向add distributed：
然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。
现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？Git提供了一个命令
git reflog
用来记录你的每一次命令：
$ git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file
从输出可知，append GPL的commit id是1094adb，现在，你又可以乘坐时光机回到未来了。
工作区（Working Directory）：就是你在电脑里能看到的目录，比如learngit文件夹就是一个工作区。
版本库（Repository）：Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
如果不用
git add
到暂存区，那就不会加入到
commit
中，也就无法提交到仓库。假如你第一次修改了文件 -> git add -> 第二次修改文件 -> git commit，此时只会commit第一次修改的内容，因为Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
为了解决这个问题，第二次修改后你可以先
git add
再
git commit
一、假如你修改了文档，可以使用
git checkout -- file
可以丢弃工作区的修改：
总之，
git checkout -- file
就是让这个文件回到最近一次
git commit
或
git add
时的状态。
注意：一定要有
--，不然就变成切换到另一个分支的指令了
二、假如你修改了文档并添加到了暂存区，但还没有提交，可以使用命令
git reset HEAD <file>
把暂存区的修改撤销掉（unstage），重新放回工作区：
$ git reset HEAD readme.txt # HEAD表示最新的版本
Unstaged changes after reset:
M readme.txt
git reset
命令既可以回退版本，也可以把暂存区的修改回退到工作区，接下来可以使用一中的指令将工作取得修改丢弃，如此，你就丢弃了暂存区的修改。
Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。所以首先需要找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。GitHub就充当这个“服务器”的角色，提供Git仓库托管服务。
前往GitHub注册账号后还需要做一些设置：
ssh-keygen -t rsa -C "youremail@example.com"
，把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。如果一切顺利的话，就可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
现在，你已经在本地创建了Git仓库，假如你又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作。
Create a new repo
按钮，创建一个新的仓库：
Repository name
填入仓库名，本文为learngit，其他保持默认设置，点击
Create repository
按钮，就成功地创建了一个新的Git仓库：
git remote add origin git@github.com:GitHub账户名/仓库名.git
，添加后，远程库的名字就是origin，这是Git默认的叫法
git push
把本地库的所有内容推送到远程库上，实际上是把当前分支master推送到远程：
$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
- [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
由于远程库是空的，我们第一次推送master分支时，加上了
-u
参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
git push origin master
，把本地master分支的最新修改推送至GitHub
当你第一次使用Git的
clone
或者
push
命令连接GitHub时，会得到一个警告：
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?
这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
。这个警告只会出现一次，后面的操作就不会有任何警告了。
如果添加的时候地址写错了，或者就是想删除远程库，可以用
git remote rm <name>
命令。使用前，建议先用
git remote -v
查看远程库信息：
$ git remote -v
origin git@github.com:michaelliao/learn-git.git (fetch)
origin git@github.com:michaelliao/learn-git.git (push)
然后，根据名字删除，比如删除origin：
git remote rm origin
此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。
一、登陆GitHub，创建一个新的仓库，然后点击【code】或者【clone】，复制地址
二、用命令
git clone
克隆一个本地库：
$ git clone git@github.com:yan7Cara/xx.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.
GitHub给出的地址不止一个，还可以用https协议的地址。使用https除了速度慢以外，还有个最大的麻烦是 每次推送都必须输入口令
你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样既安全，又不影响别人工作。
每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。这个分支叫主分支，即master分支。HEAD严格来说指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
每次提交，master分支都会向前移动一步，这样随着你不断提交，master分支的线也越来越长。当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git直接把master指向dev的当前提交，就完成了合并：
下面开始实战：
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev # 创建dev分支
$ git checkout dev # 切换分支
Switched to branch 'dev'
我们注意到切换分支使用
git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。因此，最新版本的Git提供了新的git switch命令来切换分支,创建并切换到新的dev分支，可以使用：git switch -c dev，直接切换到已有的master分支，可以使用：git switch master
git branch
命令查看当前分支：
$ git branch
* dev
master
git branch
命令会列出所有分支，当前分支前面会标一个
*
号。
Creating a new branch is quick.
，然后提交：
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)
$ git checkout master
Switched to branch 'master'
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
git merge
把dev分支的工作成果合并到master分支上：
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
Fast-forward表示这次合并是“快进模式”，也就是直接把master指向dev的当前提交
$ git branch -d dev
Deleted branch dev (was b17d20e).
如果要丢弃一个没有被合并过的分支，可以通过
git branch -D <name>
强行删除。
准备新的feature1分支，继续我们的新分支开发：
$ git switch -c feature1
Switched to a new branch 'feature1'
修改readme.txt最后一行，改为：
Creating a new branch is quick AND simple.
在feature1分支上提交：
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
切换到master分支：
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
在master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.
，提交：
$ git add readme.txt
$ git commit -m "& simple"
[master 5dc6824] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
现在，master分支和feature1分支各自都分别有新的提交，这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突：
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：
$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
我们可以直接查看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用
<<<<<<<
，
=======
，
>>>>>>>
标记出不同分支的内容，我们修改如下后保存：
Creating a new branch is quick and simple.
，再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
现在，master分支和feature1分支变成了下图所示：
用带参数的
git log
也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit
* cf810e4 (HEAD -> master) conflict fixed
|\
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file
假设你现在在dev分支上进行开发，因为你还没开发完，所以代码还没法提交，但是现在需要你新开一个bug分支修复bug，那你需要把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照，其实它就是指向某个commit的指针。因为commit id是一串数字，且不方便记忆，所以有了tag
一、切换到需要打标签的分支上：
$ git branch
* dev
master
$ git checkout master
Switched to branch 'master'
二、使用命令
git tag <name>
就可以打一个新标签：
git tag v1.0
三、可以用命令
git tag
查看所有标签：
$ git tag
v1.0
默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，我们可以找到历史提交的commit id，然后给其打上tag：
$ git log --pretty=oneline --abbrev-commit
12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101
4c805e2 fix bug 101
e1e9c68 merge with no-ff
f52c633 add merge
cf810e4 conflict fixed
5dc6824 & simple
14096d0 AND simple
b17d20e branch test
d46f35e remove test.txt
b84166e add test.txt
519219b git tracks changes
e43a48b understand how stage works
1094adb append GPL
e475afc add distributed
eaadf4e wrote a readme file
比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令：
git tag v0.9 f52c633
，再用命令git tag查看标签：
$ git tag
v0.9
v1.0
标签不是按时间顺序列出，而是按字母排序的。
可以用
git show <tagname>
查看标签信息：
$ git show v0.9
commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9) # 可以看到，v0.9确实打在add merge这次提交上。
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:56:54 2018 +0800
add merge
diff --git a/readme.txt b/readme.txt
...
还可以创建带有说明的标签，用
-a
指定标签名，
-m
指定说明文字：
git tag -a v0.1 -m "version 0.1 released" 1094adb
，使用命令
git show <tagname>
可以看到说明文字：
$ git show v0.1
tag v0.1
Tagger: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 22:48:43 2018 +0800
version 0.1 released
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:06:15 2018 +0800
append GPL
diff --git a/readme.txt b/readme.txt
...
注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
如果标签打错了，也可以删除：
$ git tag -d v0.1
Deleted tag 'v0.1' (was f15b0dd)
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。如果要推送某个标签到远程，可以使用命令
git push origin <tagname>
：
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
或者，一次性推送全部尚未推送到远程的本地标签：
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v0.9 -> v0.9
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)
然后，使用命令
git push origin :refs/tags/<tagname>
从远程删除：
$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
- [deleted] v0.9