首先理解几个基本概念：
origin：默认远程版本库；
master:默认开发分支；
（1）git log
查看提交日志。会显示出你的每一次提交。如图：
（2）git log --pretty=oneline
如果你觉得上面输出内容太多太杂，可以使用这个命令。信息会在一行显示。如图：
（3）git branch
查看当前分支。如图，我现在在master分支。
（4）git reflog
查看提交历史，以便确定你要回滚到哪个版本。根据前面的hash值或者HEAD可以进行回滚。
（5）git diff 文件名
查看你某个文件的修改前后对比。红色“-”为删除，绿色“+”为插入。修改过程就是先删除，后插入。
（6）git reset --hard 7位哈希值
回滚到某个版本。7位哈希值可以通过git reflog查到。如图：
（7）cat 文件名
查看某个文件的内容。如图：
（8）git checkout -- 文件名
把该文件在工作区的修改全部撤销，这里有两种情况：
一种是文件修改后还没有放到暂存区（也就是还没有执行git add）,现在撤销修改就回到和版本库一样的状态；
一种是文件修改后已经添加到暂存区（已经执行了git add），又做了修改，撤销修改就回到了添加到暂存区后的状态；
总之，就是让这个文件回到最近执行git commit或git add时的状态。
注意中间的"--"很重要，没有“--”，就变成了“切换到另一个分支”的命令。
（9）git reset HEAD 文件名
把暂存区的修改撤销掉（unstage）,重新放回工作区。
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区，当我们用HEAD时，表示最新的版本。
（10）git rm 文件名
在工作区中增加一个文件，并添加到本地分支中。但是如果你不需要这个文件了。你直接用"rm 文件名"删除该文件。这个时候，Git知道你删除了文件，因此，工作区和版本库就不一样了。git status可以查看当前的情况。
此时有两个选择：
1.确实要从版本库中删除该文件，就用命令"git rm 文件名"删掉，并且git commit提交，此时该文件就真正从版本库中删除了。
2.另一种情况是删错了，因为版本库中还有该文件，所以可以把误删的文件恢复到最新版本，“git checkout -- 文件名”。“git checkout”就是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
。
（11）git remote add origin ***github仓库地址
关联一个远程仓库。在第一次提交之前进行。
（12）git remote -v
查看远程仓库的地址。
（13）git remote rm origin
删除原来的远程仓库地址。
（14）git push -u origin master
第一次推送master分支的所有内容。
（15）git push origin master
以后每次的修改使用该命令。
（16）关于分支：
在版本回滚里，每次提交，Git都把他们串成一条时间线，这条时间线就是一个分支。到目前为止，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的。所以，HEAD指向的就是当前分支。
git checkout -b dev
创建一个dev分支，然后切换到dev分支。
（17）上述命令相当于以下两条命令：
git branch dev :新建一个dev分支；
git checkout dev :切换到dev分支；
（18）git branch
查看本地所有分支。前面带星号*的表示当前所在的分支。
注意：
git branch -a：查看所有分支，包括本地分支和远程分支。
本地分支用绿色和黑色显示，绿色表示你现在所在分支，黑色是其他分支。远程分支用红色表示。
git branch -r :查看远程所有分支，都以红色显示。
git branch -d dev：删除本地某一个分支，如dev分支。
（20）合并分支
1. git checkout -b dev ：首先创建一个dev分支，并切换到dev分支；
2.进行修改文件，然后提交。
.
3.cat main.m
dev分支下
发现里面我增加了“//dev分支”这几个字；
4.git checkout master：现在dev分支的工作完成了，我们就可以切换到master分支。
5.cat main
master分支下。
发现里面并没有“//dev分支”，因为那个提交是在dev分支上，而maser分支此刻的提交点并没有变。
6. git merge dev
把dev分支的工作成果合并到master分支上。
git merge 命令用于合并指定分支到当前分支。合并后，在查看文件内容，就可以看到，和dev分支的最新提交是完全一样的。
7.上面的"Fast-forward"信息，Git告诉我们，这次的合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
8.git branch -d dev
合并完成后，就可以放心的删除dev分支了。
9.分支小结：因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果使一样的，但过程更安全。
（21）解决冲突
1.git checkout -b testConflict
git add .
git commit -m "testConflict提交，测试冲突"
新建一个testConflict分支，用来测试冲突。并修改其中的一行代码；提交。
2. git checkout master
git add .
git commit -m "测试"
在master分支下，同样修改同一行代码，并进行提交；
3.git merge testConflict
此时两个分支各自有了新的提交，此时，Git无法执行“快速合并”，只能视图把各自的修改合并起来，但这种合并就会有冲突。此时合并的结果如下：
4.git 提示我们有冲突。可以通过"git status"命令来查看哪个文件有冲突。如图：
5. 我们可以直接去冲突文件查看，可以看到如下代码：
其中<<<<<,=====,>>>>>>，这种地方表示是有冲突的。可以手动进行修改，修改后代码如下：
然后在master下进行提交即可。如图：
。
6.git log --graph
可以看到分支的合并情况，如图：
注意上面："Merge: 5da331c 1225c73", 是把后面的分支合并到前面的分支。也就是把testConfict分支合并到master分支上。这个7位数是commit后面那串数字的前7位。
commit 后面那串数字是hash值，使用的是SHA-1哈希算法，40位的长度。是根据你的文件内容计算出的hash值。
7.git log --graph --pretty=oneline
可以让输出在一行显示，如图：
8. 最后把testConflict分支删除即可。注意：当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
（22）分支管理策略
1.通常合并分支时，如果可以，Git会使用Fast Forward快进模式，但这种模式下，删除分支后，会丢掉分支信息。我们可以使用--no-ff方式的git merge.
2.git checkout -b dev
仍然创建并切换到dev分支。
3.git add .
git commit -m "merge --no-ff"
在dev分支下进行提交。
4.git checkout master
切换到master分支下。
5.git merge --no-ff -m "merge with no-ff" dev
合并使用--no-ff参数，表示禁用Fast Forward。因为本次合并要创建一个新的commit，所以加上-m参数。
6.git log --graph --pretty=oneline --abbrev-commit
查看分支历史。注意使用--abbrev-commit 参数可以把commit的40为hash值缩短为7位，方便查看。
7.分支策略：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活。干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master上发布1.0版本。每个人都有自己的分支，时不时往dev分支上合并就可以了。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出曾经做过合并。而fast forward合并就看不出曾经做过合并。默认是“fast forward”.
（23）Bug分支
每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
1.git stash
把当前的工作现场储藏起来，等以后回复现场后继续使用。
git stash list
查看当前分支中存储的stash
2.git status
此时在dev分支中查看工作区，是干净的。因此可以放心的创建分支来修复bug。
3.git checkout master
git checkout -b issue-101
首先确定要在哪个分支上修复bug，假定要在master分支上修复，就从master创建临时分支。
4.在issue-101上修复bug，提交。
5.git checkout master
git merge --no-ff -m "修复完成，合并issue-101分支" issue-101
git log --graph --pretty=oneline --abbrev-commit
合并bug分支。
6.git branch -d issue-101
删除bug分支。
7.git checkout dev
git status
再次回到dev分支干活，工作现场是完全干净的。
8.git stash list
查看当前的工作现场。Git把stash内容存储在某个地方了。我们需要恢复现场。
9.git stash pop
git stash list
在恢复内容的同时把stash的内容也删了。
10.git stash apply
git stash drop
这两行命令相当于“git stash pop”. 用“git stash apply”恢复，但是恢复后，stash内容并不删除，需要用“git stash drop”来删除。
11.git add .
git commit -m "在dev分支提交"
把dev分支工作的内容提交。等下要合并到master分支。
12.git checkout master
git merge --no-ff -m "合并dev分支的工作内容" dev
如果有冲突，则手动修改。
13.git add .
git commit -m “合并了dev后的master提交”
git branch -d dev
手动解决冲突后，在master提交，然后删除dev分支。
14.小结：修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除。
当手头工作没有完成时，先把工作现场git stash 一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
（24）Feature分支
1.添加一个新功能，你肯定不希望因为一些实验性质的代码，把主分支搞乱了。所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后删除feature分支。
当开发完成后，如果在还没有合并之前，这个新功能不需要了。就需要删除该分支。
git branch -d feature-net
.
2.git branch -D feature-net
注意：1中的删除无法成功，因为该分支还没有被合并，如果删除，将丢失修改。如果要进行强行删除，要使用"git branch -D feature-net"命令。
。
3.小结：开发一个新的feature,最好新建一个分支。如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。
（25）git remote
查看远程库的信息。
git remote -v
显示详细信息。显示了可以抓取和推送的origin地址。如果没有推送的权限，就看不到push的地址。
（26）多人协作
1.推送分支：就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上。
git push origin master
如果要推送到其他分支，比如dev，就改成：
git push origin dev
但是并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些分支不需要呢?
--master分支是主分支，因此要时刻与远程同步；
--dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
--bug分支只用于在本地修复bug，没必要推送到远程；
--feature分支可以看实际开发需要。
2.抓取分支
git checkout -b dev origin/dev
创建远程origin的dev分支到本地。
git branch --set-upstream dev origin/dev
设置本地dev与远程origin/dev分支的链接。
3.多人协作的模式：
--首先，可以试图用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".
4.小结
--查看远程库信息，使用“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.如果有冲突，要先处理冲突。
（27）标签管理
发布一个版本时，我们通常先在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Gitde 标签虽然是版本库的快照，但其实他就是指向某个commit的指针。所以，创建和删除标签都是瞬间完成的。
（28）创建标签
git tag v1.0
切换到要打标签的分支上，执行“git tag v1.0”,默认是打在最新提交的commit上。
git tag
查看所有的标签。
git tag v1.1 commit_id
标签可以打在任意一个提交上。
git show v1.0
查看标签信息。
（29）操作标签
1.git tag -d v1.0
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
2.git push origin v1.0
推送某个tag到远程分支。
3.git push origin --tags
一次性推送全部尚未推送到远程的本地标签。
4.如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git tag -d v1.0
然后从远程删除。删除命令也是push，但是格式如下：
git push origin :refs/tags/v1.0
5.小结：
--命令“git push origin <tagname>”:可以推送一个本地标签；
--命令“git push origin --tags”:可以推送全部未推送的本地标签；
--命令"git tag -d <tagname>":可以删除一个本地标签；
--命令“git push origin :refs/tags/<tagname>”:可以删除一个远程标签。
2.git status
此时在dev分支中查看工作区，是干净的。因此可以放心的创建分支来修复bug。