由于之前写一个Spring项目的时候是自己和一位大佬一起协作的，在中间差点因为我的git命令不熟悉而导致我的本地分支错误合并。这里仔细写一下git创建分支时候的一些坑和解决分支冲突时候的一些方法。
先写一下一些比较常用的命令
版本回退命令
git reset --hard 版本号
版本回退后后悔了怎么办?
先
git reflog
查看未来的版本号
然后
git reset --hard 版本号
想要让git log --graph看到的东西更好看
不妨使用
git rebase branch
你会有一些惊喜的发现
下面进入正文
创建分支
我们可以使用
git checkout -b dev
创建一个名为dev的分支， 并将HEAD指针指向dev分支
这需要加入一个-b参数
它的效果等同于
git branch dev
git checkout dev
而分支的意义在于当使用git来进行团队协作的时候，我们需要各自独立实现自己的所负责的功能，但是很显然我们不可以把所有工作都放到master分支中，这就是我们的创建分支的必要，每个人将自己创建的分支中进行分支合并到master主分支。
我们使用
git merge branch
合并分支，
接着我们可以放心的删除dev分支了，我们使用
git branch -d dev
删除dev分支
解决分支冲突
当master的版本高于分支的版本的时候这个时候合并分支
git merge branch_name
会产生分支冲突。
- 这个时候可以先使用git的自动智能合并
git pull
- 如果提示失败，那么这个时候可以自己手动解决分支冲突(就是自己按照git在文件中的提示删除master分支或者自己创建的分支的内容)，然后再将这个改动提交
我们可以使用带参数的一个log命令看到中间的一个过程
git log --graph
我的实验过程是这样的
分支管理策略
通常合并分支是，Git会使用Fast Forword模式，但是这个模式在删除这个分支后就会丢掉这个分支信息。所以如果强制禁用Fast Forword模式，git就会在merge的时候生成一个新的commit
我们使用
git merge --no-ff -m "logs here" branch_name
这个我们这个分支合并动作就会作为一次commit从而记录在master了.
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
到这里差不多把平时踩过的坑都写了一遍
参考资料：廖雪峰的博客