背景
git 现在已经成为我们日常生活中普遍的工具了，其实有时候还是有一些疑问的，毕竟很多东西即使你之前学过了，当你用的时候还是有点不确定，一般我都会在本地做一下测试，避免给生产环境的git代码库带来问题,毕竟这决定了你一个人的态度。
补充
我们都知道git是一个分布式的代码管理工具，因为是分布式每个人都可以在自己的本地仓库进行操作以及提交，最后可以push到remote repository。但是我们在push之前，应该pull一下，因为如果有相同的文件修改了会出现问题，其实git pull 这个操作还是不太好的，因为他不够直观
git pull //相当于下面两个操作
git fetch
git merge
git fetch 会把此分支上面所有的更新拉下来，但是没有和本地的Head分支进行和合并。
如果执行git fetch后再去执行 git merge就会把更新的部门和当前的Head进行合并，如果有冲突就会产生冲突文件，然后把冲突文件修改一下就可以了。
探索
我们用本地的一个仓库去模拟一下git merge产生冲突时候的情况。
git init //初始化一个本地仓库
echo "master" > info.txt
git add .
git commit -m "master"
//在上面master的基础上创建两个新的分支
git branch issue1 //创建一个issue1 本地分支
git branch issue2 //创建一个issue2 本地分支
这里要注意点，这两个分支都是从master分支产生的，此时这三个分支都是在一个点，对于git来说，这三个分支的指针是一样的，这里需要支出的是HEAD指的就是当前的分支，每当我们git checkout 分支的时候，HEAD也会自动的修改指向切换后的分支。
我们可以这样去查看HEAD:
cat .git/HEAD
ref: refs/heads/master //输出
接下来进入正题，首先切换到issue1分支:
git checkout issue1
echo "issue1" >> info.txt
git add .
git commit -m "issue1"
//下面是issue1操作结果
[issue1 4e5bb48] issue1
1 file changed, 1 insertion(+)
然后切换到issue2:
git checkout issue2
echo "issue2" >> info.txt
git add .
git commit -m "issue2"
//下面是issue2的操作
[issue2 bcf0fb0] issue2
1 file changed, 1 insertion(+)
然后我们再切换到master分支把issue1和issue2merge到master分支,不过在我们merge之前我们想思考一下，假设我们先merge issue1分支，然后再merge issue2分支会出现什么样的结果呢?
因为issue1 和 issue2都是从master分支创建出来的，所以master分支merge issue1的时候是可以成功的，因为在master分支在merge issue1的时候，master分支并没有改动过，但在master merge issue2的时候，就会有问题，因为此时master以及修改了，而且修改的地方还都存在冲突，冲突就是第二行。
master合并issue1分支:
Updating e84213a..4e5bb48
Fast-forward
info.txt | 1 +
1 file changed, 1 insertion(+)
上面的Fast-forward指的就是把master当前的指针直接移动到issue1 也就是ｍaster此时和issue1指向一个位置。
master再合并issue2分支:
Auto-merging info.txt
CONFLICT (content): Merge conflict in info.txt
Automatic merge failed; fix conflicts and then commit the result.
从上面可以看出，出现了冲突。
cat info.txt
//结果如下
master
<<<<<<< HEAD //HEAD到分界线是当前分支的(master)
issue1
======= //这个是分界线
issue2
>>>>>>> issue2 //分界线到此处是合并分支的(issue2)
因为第二行出现了冲突,master merge issue1后第二行为issue1
然后此时merge issue2的时候 第二行为issue2，所以出现了冲突，
修改一下，然后提交就可以了。
网友评论