一、分支
1、分支简单介绍
简单使用:
可以将git branch new_branch和git checkout new_branch两个命令合并成一个命令:git checkout -b new_branch。这个命令的意思就是创建一个分支并且切换到这个分支上。
本地分支改名:git branch -m 原分支名 新分支名
2、合并分支merge
这个过程中，下一个版本会记录一个parent id，这个parent id就是前一个版本的commit id。
注意当我们在dev中更改文件之后，一定要先add和commit，不然那样就会和master内容同步了，我们需要的是在dev中更改之后，在没有进行merge之前，master不会和dev相同: 看下面的演示：
3、快进fast forward
HEAD的含义: (在git reset HEAD test.txt中使用过)
HEAD指向的是当前分支；
master是指向提交(本质上只的是当前的提交)；
即如下表示:
如果我们执行git checkout -b dev，我们就会创建一个dev分支并指向新的分支。
这是在master分支的基础上，但是这个过程并不是像SVN一样会拷贝一份，而是只是创建一个指针dev，会和master指向了同一个提交。但此时HEAD指向的是dev（当前分支）。
查看HEAD文件的内容:
然后我在上图的基础上，如果我在dev分支下进行了一次提交，图就会变成下面这样:
此时master指向第3次提交，而dev已经指向了第四次提交。
接下来，如果我将dev上面的修改合并到master上面 (在master中操作)，上面的图就会变成下面这样:
这种情况不会有冲突存在。
实战演示:
总结一下这种情况，就是直接从master分支跳转到了最后的dev修改的那个位置，相当于指针的跳转。
4、master和dev同时修改同一文件同一位置产生冲突
演示冲突：在master中修改了test.txt的第三行，在dev中也修改了test.txt中的第三行，于是合并的时候就会产生冲突:
上面的过程就是如下图的过程:
注意箭头往回指是因为后一个提交里面包含一个parent-id指向前一个提交的commit-id，前面已经说过。
注意观察master分支中test.txt文件的内容以及我们将解决这次冲突(即我们打算保存master的修改而丢弃dev的修改)：
5、深入fast-forward模式
也就是说在fast-forward模式下:
如果可能（合并时没有冲突），那么Git就会采用
fast-forward模式；在这种模式下，删除分支时会丢掉分支信息；
合并时加上
-- no-ff参数会禁用fast-forward模式，这样就会多出一个commit - id，也就是说在fast-forward模式下面merge不会多出一个commit-id；
git merge -- no-ff dev
查看日志更好的方式
git log --graph
关于fast-forward模式和非fast-forward模式下的少一次commit-id和多一次commid-id的图解:
我们先看使用fast-forward模式下的: (即合并的时候commit-id和另一个分支相同):
再看不使用fast-forward模式:
二、Git版本回退
Git的另外一个强大之处在于可以回退到之前的任意一个版本：
主要看下面的命令:
git reset --hard HEAD^， 往后回退1个版本；git reset --hard HEAD~3，往后回退3个版本；git reset --hard commit-id，直接回退到某个commit-id；(如果当前在靠前面，就可以通过git log查看)；如果在后面，不能查看到前面的
git log 得到 commit-id怎么办呢？可以用git reflog查看自己的操作日志；
实战演示:
查看修改和提交日志:
下面演示怎么回退:
原文：Java架构笔记