=======================版本回退===============================
readme.txt(one、add2、add3版本的内容如下)
 hello world       one 
 hello world 2     add2
 hello world 3     add3
[root@localhost repotest]# git log --pretty=oneline
311970aa676a3efa30f018a1079e6f093dad0b53 add 3
73b3b44fcbcf4b94577bf708d91b8c79295195dc add 2
f3bab092683efbb5f1600002e17d4960f13d5133 one

[root@localhost repotest]# ls
readme.txt

[root@localhost repotest]# git reset --hard HEAD^ (上一个版本就是HEAD^，上上一个版本就是HEAD^^，
当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。)
HEAD is now at 73b3b44 add 2
[root@localhost repotest]# cat readme.txt 
hello world
hello world 2
[root@localhost repotest]# 

在Git中，总是有后悔药可以吃的。当你用$git reset --hard HEAD^回退到add distributed版本时，
再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记
录你的每一次命令：
[root@localhost repotest]# git reflog
73b3b44 HEAD@{0}: reset: moving to HEAD^
311970a HEAD@{1}: commit: add 3
73b3b44 HEAD@{2}: commit: add 2
f3bab09 HEAD@{3}: commit (initial): one
现在总结一下：

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令
git reset --hard commit_id。

穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。

要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
=================工作区和暂存区========================
图 版本库

在工作区新增一个LICENSE文本文件（内容随便写）。
先用git status查看一下状态：
[root@localhost repotest]# vim license
git 1
[root@localhost repotest]# git status
 On branch master
 Untracked files:
   (use "git add <file>..." to include in what will be committed)

    license
nothing added to commit but untracked files present (use "git add" to track)
[root@localhost repotest]# git add license (license就放到暂存区了)
[root@localhost repotest]# git status
 On branch master
 Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   license
[root@localhost repotest]# git commit -m "1" license （放到了master）
[master 37443a9] 1
 1 file changed, 1 insertion(+)
 create mode 100644 license
[root@localhost repotest]# git status
# On branch master
nothing to commit, working directory clean
==================管理修改=================================
第一次修改 -> git add -> 第二次修改 -> git commit
在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，
也就是第一次的修改被提交了，第二次的修改不会被提交。
经实验第二次修改的也提交上去了（？？）

那怎么提交第二次修改呢？
第一次修改 -> git add -> 第二次修改 -> git add -> git commit
===========================撤销修改====================
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
[root@localhost repotest]# cat readme.txt 
hello world
hello world 2
boss sb
[root@localhost repotest]# 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
#

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，
第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前
提是没有推送到远程库。
==========================删除文件==============================
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，
但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
[root@localhost repotest]# vim test.txt
[root@localhost repotest]# git add test.txt 
[root@localhost repotest]# git commit -m "add test.txt"
[master 5beda0e] add test.txt
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt
[root@localhost repotest]# rm test.txt
rm: remove regular file ‘test.txt’? y
[root@localhost repotest]# ls
license  readme.txt
[root@localhost repotest]# git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
[root@localhost repotest]# git rm test.txt
rm 'test.txt'
[root@localhost repotest]# git commit -m "remove test.txt"
[master 1506a3f] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt
=======================分支=========================
Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

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

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

删除分支：git branch -d <name>
=======================解决冲突=====================================
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/
001375840202368c74be33fbd884e71b570f2cc3c0d1dcf000
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

图冲突1

首先，仍然创建并切换dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件，并提交一个新的commit：

$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)
现在，我们切换回master：
====================分支管理策略==================================
$ git checkout master
Switched to branch 'master'
准备合并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描述写进去。

合并后，我们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...
可以看到，不使用Fast forward模式，merge后就像这样：
33333333

分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如
1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev
分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

======================修复bug================================
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，
再git stash pop，回到工作现场。
===================开发一个新feature=========================
开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

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

首先，可以试图用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，如果有冲突，要先处理冲突。
=============================创建标签===========================
在Git中打标签非常简单，首先，切换到需要打标签的分支上：
$ git branch
* dev
  master
$ git checkout master
Switched to branch 'master'
然后，敲命令git tag <name>就可以打一个新标签：

$ git tag v1.0
可以用命令git tag查看所有标签：

$ git tag
v1.0
创建标签
阅读: 257248
在Git中打标签非常简单，首先，切换到需要打标签的分支上：

$ 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，然后打上就可以了：

$ 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)
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
...
可以看到，v0.9确实打在add merge这次提交上。

还可以创建带有说明的标签，用-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 <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；

命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
==============================删除标签================================
小结
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
然后，从远程删除。删除命令也是push，但是格式如下：
命令git push origin <tagname>可以推送一个本地标签；

命令git push origin --tags可以推送全部未推送过的本地标签；

命令git tag -d <tagname>可以删除一个本地标签；

命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
命令git tag可以查看所有标签。

版本库.png

冲突1.png

冲突2.png

3.png

由于git init –bare 方法创建一个裸仓库，在该仓库无法进行任何git操作，所以抛出错误.

解决方法：在该仓库目录下，新建文件夹，进入该文件夹，执行如下命令：
1. touch Readme
2. git init
3. git add Readme
4. git commit -m 'initial commit' Readme