产生冲突的常见原因
1.基于同一分支，在当前代码非服务器最新版本代码的情况下进行提交操作或者是更新操作产生
问题案例：
小明和小芳用的是同一个分支，小明把代码修改完后提交到远端，小芳不知道小明已经提交了修改，没有从远端更新代码到本地，然后在基于本地的代码作了修改，如果小芳修改的位置和小明修改的位置一致，那么小芳的无论是提交代码还是拉取代码，都将与小明的修改产生冲突。
解决方式：
小明提交代码后，通知小芳对自己本地的代码进行拉取更新操作，或者小芳在修改代码之前对小明进行询问；反之亦然。
2.基于两个或以上不同的分支，修改的位置一致，在合并时产生
问题案例：
小明在 feat-Ming 分支修改了A文件的第N行，然后merge代码到 master ，小芳在 feat-Fang 分支也修改了A文件的第N行，那么在小芳merge代码到 master 的时候，小芳将会看到自己的代码与小明产生冲突。
解决方式：
小芳先别急着在 feat-Fang 上修改冲突，然后merge到 master ，这样会使自己的 feat-Fang 失去原来的代码记录痕迹。
为了更好保留这些代码痕迹，以及维持 master 的稳定性。小芳这边可以通过以 master 为母本新建 中间分支 ，然后把 feat-Fang 代码merge到 中间分支 ，此刻产生了与merge到 master 时一样的冲突，小芳就要找小明协商两人写的代码如何进行取舍等问题，共同把冲突修好之后，再把 中间分支 merge到 master ，如此便能确保merge到 master 的结果的正当性以及保留 feat-Fang 代码痕迹。
个人理解：
原以为，冲突是因为时间线上的碰撞才产生的，认为只要不在同一时间点上竞争merge的优先权，把时间错开就不会发生，后者会把前者覆盖。其实不然。
不同分支merge到主分支，然后修改的位置相同而修改后的内容不一致，就会导致主分支不知道哪个修改版本为准，所以产生冲突，但是这与merge时间没有关联性。
A分支在merge回主分支的时候，会通过与 A分支和主分支的最近公共父提交节点 做比较，识别出changes的内容，姑且称之为 changesA ，然后把 changesA 覆盖进主分支，这个 changesA 只能是唯一的，B分支在merge回主分支的时候，所产生的 changesB 不可以与 changesA 有交集。
