Git 分支管理基础与策略

在当前分支提交修改后的 ReadMe 文件。

在当前分支修改 ReadMe 文件。

造成上面的结果，是因为两个分支执行的提交是不一样的。

合并分支

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

Fast-forward 代表'快进模式'，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward。

删除分支

完成合并分支的操作后，dev 分支的使命也就结束了。使用 git branch -d [分支名] 就可以删除该分支了。

注意不能在该分支目录下直接删除，不被允许。

合并冲突处理

情景：当本地分支 dev 修改文件时，master 分支同时也在修改该文件，Git 无法自动决定保留哪个版本。

本地修改：

master 分支修改：

合并造成冲突：

ReadMe 文件此时需要手动选择保留哪个代码。

重新 add commit 和 merge 即可：git log --graph --pretty=oneline --abbrev-commit 查看分支合并情况。

强制禁用 Fast Forward

默认 merge 提交，Git 是 fast forward 直接修改 master 指向的方式。通过 fast forward 模式会有删除分支后，查看分支信息的时候没有记录的情况出现。

Git 支持使用 --no-ff 强制禁用 Fast forward 模式，这样会在 merge 时生成一个新的 commit，从分支历史上可以看出是合并过的。

语法：

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

分支管理策略

master 主分支要保持稳定的。

由于多人可以在 master 拉分支实现开发，团队合作的分支结构如下：

Bug 分支与 Stash

情景：假如正在 dev 分支上进行开发，开发到一半，突然发现 master 分支上有 bug，需要解决。每个 bug 可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。此时 dev 还没开发完，无法提交。

Git 提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。

使用了 stash 命令之后，就可以在 master 分支上创建分支修改 bug，修改完成后提交。如何继续 dev 的开发工作？直接切回去后，是没有当时没写完的代码的。

使用 git stash pop 命令恢复工作区代码。

另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash 内容并不删除，需要用 git stash drop 来删除；

可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令 git stash apply stash@{0}。

写完 dev 分支代码后，跟 master 合并，master 在前面跟修改 bug 的分支合并了，此时就可能导致 dev 和 master 合并冲突，去手动修改冲突有可能又出现 bug。

解决方法：在自己分支上合并下 master，再让 master 去合并 dev，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master。

强制删除分支

情景：当我们开发的这个分支代码突然不需要了。要删除已经 commit 的分支，就要使用 git branch -D [分支名] 删除。