Git操作-分支管理(二)

解决冲突

场景：创建一个新的分支feature1，然后在README.txt文件里添加4 create a branch named feature1，然后在feature1分支上提交。提交后切换到master分支，再在master分支上将最后一行修改为create a new branch named feature1，再提交，现在，master分支和feature1分支各自都分别有新的提交：

此时结构图是这样的：

在这种情况下，我们尝试把两个分支合并，git merge feature1：

提示README.txt文件有冲突(conflict)，需要解决冲突后再提交，此时看一下文件内容：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，
将冲突部分手动修改后保存：4 create a branch named feature1，再提交，发现冲突解决了：

此时的分支结构图如下：

然后就可以删除分支feature1了

注：当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
用git log –graph命令可以看到分支合并图。

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward模式合并就看不出来曾经做过合并。但这种模式下，删除分支后，会丢掉分支信息。通常，合并分支时，如果可能，Git会用Fast forward模式。。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息

举个例子：在feature1分支上添加一行：fast forward，然后提交到feature1分支，切换到master分支，合并feature1分支，注意–no-ff参数，表示禁用Fast forward，命令$ git merge --no-ff -m "merge with no-ff" feature1，因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
*   59bc1cb conflict fixed
...

注意

如果在master分支上修改内容后但未提交，此时要切换到其它分支会出错：