教程源自 廖雪峰老师的博客,在此表示感谢，知识的先行者。
设置全局的用户信息
一般的开发环境是建立在windows上的：所以记录win的使用方法（其他系统大同小异）
$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"
1.常用命令
最开始应是初始化
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
添加git监管的文件(添加到暂存区)
git add
提交到本地仓库(一般来说每次提交都要添加 -m 参数，已标注此次修改的内容)
$ git commit -m "wrote a readme file"
查看当前git的状态（那些文件更改，那些文件添加）
$ git status
输出(因项目各异)
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: target/m2e-wtp/web-resources/META-INF/maven/huahai.com/SmartWeb/pom.properties
Untracked files:
(use "git add ..." to include in what will be committed)
.classpath
.idea/
.project
.settings/
查看上一次修改的具体内容
git diff
显示的格式正是Unix通用的diff格式。例如：
--- a/.classpath
+++ b/.classpath
@@ -33,7 +33,7 @@
+ ^M
diff --git a/.project b/.project
index 4ef05cf..e71384a 100644
--- a/.project
+++ b/.project
@@ -25,8 +25,19 @@
+ ^M
+ org.springframework.ide.eclipse.core.springbuilder ^M
+ ^M
+ ^M
+ ^M
+ ^M
+ org.springframework.ide.eclipse.boot.validation.springbootbuilder ^M
+ ^M
+ ^M
+ ^M
+ org.springframework.ide.eclipse.core.springnature ^M
org.eclipse.jem.workbench.JavaEMFNature
org.eclipse.wst.common.modulecore.ModuleCoreNature
org.eclipse.jdt.core.javanature
diff --git a/Dev/ReadMe.txt b/Dev/ReadMe.txt
index bb984fb..33ddc88 100644
查看git 仓库的提交历史
$ git log
输出，例如（每一次提交都会生成一个唯一标识的id，此id在同一时空中只有一个）：
commit 69322bc293e87e2910fa45896ea3f9ed15fd3a36 (HEAD -> master, origin/master)
Author: webapp <[email protected]>
Date: Fri Aug 17 18:11:15 2018 +0800
修改请求路径的统计
commit 1e3ade674254661f0033636e928a0d97fe3a3d33
Author: webapp <[email protected]>
Date: Fri Aug 17 15:41:08 2018 +0800
添加相关注释，解决javadoc报错
commit 61f285cf1caed8fc33081921aa1296de449c2eaa
Author: webapp <[email protected]>
Date: Fri Aug 17 11:24:38 2018 +0800
天级数据和小时级数据的小区级excel数据改为下载全部数据，拦截器添加请求路径的
单独拦截
commit d275ed92f9e8faa3a45e6a346d0526c937c7259c
Author: webapp <[email protected]>
Date: Thu Aug 16 17:35:06 2018 +0800
:...skipping...
回撤到上一次提交的状态(HEAD类似是一个指针，他一般情况下执行最新的一次提交)
$ git reset --hard HEAD^
想要回到更早之前的某个版本,除了使用HEAD，进行版本回退。还可以直接输入commit的id，id可以用过git log查看
$ git reset --hard
查看之前的的命令操作(用git reflog查看命令历史，以便确定要回到未来的哪个版本)
$ git reflog
放弃工作区的修改(暂未add 的前提下)(git checkout -- file) --很重要，没有--，就变成了“切换到另一个分支”的命令git checkout为切换分支的命令
git checkout -- readme.txt
如果错误的文件已经 add 进入了暂存区。那么git reset HEAD
$ git reset HEAD readme.txt
删除文件并提交
$ git rm test.txt
rm 'test.txt'
$ git commit -m "remove test.txt"
如果删错，则：(同样注意--)
$ git checkout -- test.txt
到此就是git最常用的命令，SVN也有相同的功能，那git的优势又在哪里？
优势： Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
- 为git的远程仓库添加SHHkey
$ ssh-keygen -t rsa -C "[email protected]"
如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
- 登陆GitHub，打开“Account settings”，“SSH Keys”页面：
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容 - 在github添加远程仓库（最后调整到SHH页面）
4.本地绑定远程仓库(根据github的提示切换成你自己的命令)
$ git remote add origin [email protected]:michaelliao/learngit.git
5.推送本地到远程（把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令,第一次提交会有安全提示，选择yes就行）
$ git push -u origin master
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
本地克隆远程仓库
$ git clone [email protected]:michaelliao/gitskills.git
优势：其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
创建dev分支（一般情况下，我们开发不会直接在master主分支上开发，每个开发组员，第一回在自己的dev分支上进行开发，master只进行最稳定版本的发布。）
首先，我们创建dev分支，然后切换到dev分支：
$ git checkout -b dev
切换分支 (git checkout
git checkout dev
加上-b参数表示创建并切换，相当于以下两条命令:
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
查看当前分支(git branch命令会列出所有分支，当前分支前面会标一个*号。)
$ git branch
合并分支(下面的操作意味着，将dev分支合并到当前分支上。)
$ git merge dev
合并完成后，就可以放心地删除dev分支了：
$ git branch -d dev
但是git合并分支并非都能成功，假如你要合并的分支都在原节点的同一个文件上进行了修改，那git就不知道以谁为准了。这时就会因为文件冲突而合并失败
这种情况下，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 ..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：
例如：
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 log 查看分支合并的情况（用git log --graph命令可以看到分支合并图。）
$ git log --graph --pretty=oneline --abbrev-commit
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
可以用--no-ff方式的git merge：
$ git merge --no-ff -m "merge with no-ff" dev
然后查看合并日志
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
git还提供了stash的功能，可以先把当前的的工作现场保存起来。（当代码写了一半，不方便直接commit的时候可以使用此功能）
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
查看储藏列表
$ git stash list
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：
恢复指定的stash 最后为stash的标识，可以通过git stash list 查看
$ git stash apply stash@{0}
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
1.首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
2.那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
删除一个没有提交的分支（开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).