Git、GitLab、idea插件

由于公司饱受svn折磨，所以下决心把代码级别的版本控制由svn切换到git，
项目管理文档之类的沿用svn，因此需要写一篇入门级别的文章系列，至少涵盖
大部分开发所需要的命令与常用功能的介绍，这里我参考了廖大神的git入门
，教程的重点不是成为一个git大神，也不需要成为git大神，git仅是工具，希望
大家不要本末倒置。（这篇教程是整合了网络上一些大神的文章与
自己本人的一些理解）希望帮助大家更好的使用git带来的便利。

git冲突本质

文档这处有问题，git怎么判断是否冲突的，这个由三路合并算法与递归三路合并算法判断的，接下来简单讲解下这个问题

• 三路合并算法
  

第几行代码	版本父类	版本A	版本B	是否冲突	最终合并后的版本
1	aaa	aaa	bbb	不冲突	bbb
2	aaa	cccc	aaa	不冲突	cccc
3	aaa	bbb	ccc	冲突	需要自己处理

通过a与b最短路径找到了版本公共父类，通过每行与父类对比，只有两个版本与父类都不同，才会产生冲突。

• 递归三路合并算法
  版本a与版本b存在两个最短路径的公共父类，然后通过两个公共父类，接着找最短路径公共父类，这样一直迭代，获取最终的最小父类来做对比。

快进式合并与非快进式合并

• 快进式合并

默认情况下，当使用 git merge 合并代码时，背后实际上是进行了一次“快进式合并”：

$ git checkout master
$ git merge feature-test

什么是“快进式合并（fast-forward merge）”？如果顺着一个分支走下去可以直接到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。

• 非快进式合并

作为对比，加上 --no-ff 参数进行“非快进式合并（no-fast-forward merge）”：

$ git checkout master
$ git merge --no-ff feature-test

其祖先图谱如下：

可见，合并后保留有分支历史痕迹（每一次提交），能看得出来曾经做过分支合并，版本演进比较清晰。

• 压缩合并

但大多数时候，没有必要把特性分支的历史保留得太细，只需把整个特性分支压缩（squash）为主干上的一个提交即可。这样的祖先图谱既清晰，又能方便后人审查代码，推荐使用：

$ git checkout master
$ git merge --squash feature-test
$ git commit

pdf

由于文章较长，可以去这个地址
想赚点积分哈，如果想要的没有积分可以留下邮箱，看到了后就发给你。（文章中有不妥之处 敬请斧正）