Git 分支管理实战指南

造成这种结果是因为两个分支执行的提交路径不同，相当于下图所示的分叉结构。

合并分支

为了在 master 主分支上看到新的提交，需要将 dev 分支合并进来。使用 git merge [分支名] 操作，合并后就能在 master 上看见修改后的内容了。

此时结构变成了：

默认情况下，Git 会使用 Fast-forward 模式，直接把 master 指向 dev 的当前提交，速度非常快。当然，并非每次合并都能走这条捷径。

删除分支

合并完成后，如果 dev 分支的使命结束，可以使用 git branch -d [分支名] 删除它。

注意，不能在当前所在的分支目录下直接删除该分支，Git 会阻止此类操作。

处理合并冲突

当本地分支 dev 和 master 同时修改了同一个文件的同一部分内容时，Git 无法自动判断保留哪一方，这时就会发生冲突。

本地修改示例：

master 分支也进行了修改，合并时触发冲突提示：

此时需要手动编辑 ReadMe 文件，决定保留哪些代码：

解决冲突后，重新 add、commit 并再次 merge 即可。可以用 git log --graph --pretty=oneline --abbrev-commit 查看分支合并情况。

强制禁用 Fast forward 模式

前面提到过，默认合并采用 Fast-forward 模式，直接将主分支指针移向新分支。但这会导致删除分支后，查看历史时看不出这段修改是合并进来的还是原本就在 master 下的。

为保留清晰的合并记录，Git 支持使用 --no-ff 参数强制生成一个新的 commit。这样从分支历史上就能明确看出是合并过的。

语法如下：

git merge --no-ff -m "描述" [分支名]

分支管理策略

master 主分支必须保持相对稳定。多人协作时，大家通常从 master 拉出功能分支开发，最后再合并回来。

团队协作的分支模型大致如下：

临时修复 bug 与 stash

假如正在 dev 分支开发，突然 master 上有紧急 bug 需要修。此时 dev 还没写完，没法提交。每个 bug 都可以通过一个临时分支来修复，修完合并后再删掉临时分支。

Git 提供了 git stash 命令，可以将当前的工作区信息暂存起来，稍后恢复。

执行 stash 后，我们可以去 master 分支修 bug 并提交。那如何继续 dev 的开发呢？直接切回去会发现代码没了，需要用 git stash pop 恢复现场。

也可以用 git stash apply 恢复，但不会删除 stash 记录，需手动用 git stash drop 清理。支持多次 stash，通过 git stash list 查看，并用 git stash apply stash@{0} 恢复指定记录。

写完 dev 分支代码后跟 master 合并，如果之前 master 已经合并过 bug 分支，可能会导致冲突。解决方法是在自己的分支上先合并 master，解决本地冲突并测试，确认无误后再让 master 合并 dev，避免影响主线。

强制删除分支

如果某个分支代码完全不需要了，且已 commit，可以使用 git branch -D [分支名] 强制删除。