Git 分支管理与冲突解决

Git 分支提供了并行工作的功能。 假设你准备同时学习 git 和 SVN，你可以用两个分支分别来学习，完成之后进行合并，你就掌握了两种工具的使用了。 Git 和 GitHub 的基本操作可以参考我的这篇博客Git 和 GitHub 使用。

1. 分支管理

• 查看分支 git brance

• 创建分支 git branch dev # dev 是分支名

• 切换分支 git checkout dev

• 创建+切换 git checkout -b dev

• 合并分支 git merge dev #分支 dev 合并到 master

• 删除分支 git branch -d dev #已合并的分支

• 强行删除分支 git branch -D dev #分支未合并
• 查看分支图 git log –graph

远程仓库的分支

当你从远程仓库克隆时，实际上 Git 自动把本地的 master 分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

如果要在远程仓库的其他分支 (如 dev 分支)上开发，就必须创建远程 origin/dev 分支到本地：

    git checkout -b dev origin/dev       #创建远程仓库的分支到本地，必须先克隆或关联一个远程分支

本地分支和远程分支的名字最好一致。

推送成功之后, GitHub 上的 MyRepos 仓库 dev 分支上增加了一个文件。

2. 分支合并模式

Fast forward 模式

默认模式，在这种模式下, 删除分支后，会丢掉分支信息，看不到合并记录.。并不是任何情况都能用这种模式。

普通模式

加上 --no-ff 参数就是普通模式。在普通模式下, Git 会在 merge 时生成一个新的 commit，这样从分支历史上就可以看出分支信息。

普通模式

快进模式

分支图

在分支图中, 红线是子分支 dev, 绿线是主分支 master. 子主分支分别提交了一次修改, 在将 dev 合并到 master 时发生冲突, 修改冲突文件内容之后再提交。

3. 解决冲突

如果两个分支都分别有了新的提交，Git 无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。必须手动解决冲突后再提交。git status 也可以告诉我们冲突的文件。

内容冲突

两个分支对同一文件的内容进行了修改并分别提交, 如果合并失败, 就必须手动解决冲突, 修改文件的内容之后再进行提交。

在冲突内容中, Git用<<<<<<>>>>>>标记出不同分支的内容. 文件的内容可以协商修改。

树冲突

一个分支修改了内容, 另个一分支删除了文件, 在试图合并时就会出现树冲突。假设子分支(如 dev)是要合并到主分支 master 的, 处理的方法有：

放弃 dev 的修改：强制删除 dev 分支, 然后提交即可。

放弃 master 的修改—-分下面两种情况：

1. master 修改了内容, dev 删除了文件： 在 master 分支中删除该文件, 然后提交；
2. master 删除了文件, dev 修改了内容： 在 master 分支中添加被修改的文件, 然后提交。

master 修改了内容, dev 删除了文件：

master 删除了文件, dev 修改了内容：

对于文件的移动(在 Git 仓库目录范围内)和重命名, Git 都可以自动合并。

远程仓库推送冲突

• 从远程分支抓取最新的提交 git pull

• 建立本地分支与远程分支的连接 git branch –set-upstream dev origin/dev # dev 为分支名

如果推送出现冲突， 先将远程分支最新的提交抓取下来， 在本地解决冲突之后再推送。解决冲突的方法与本地冲突完全相同