⼤⽩话git教程-08-分⽀合并和典型⽤法
分⽀就是暂时从主线代码离开，去专注于开发⼀个新特性或者解决⼀个⼩ bug，git 创建和切换分⽀都能在瞬间完成，默认的 git 仓库，输⼊ git branch 可以看到只有⼀个 master 分⽀，通常这就是主分⽀。
wangbo@wangbo-VirtualBox:~/test/git-demo$ git branch* master
假设现在需要开发⼀个打印的新特功能，分⽀名称为 feature_print，从 master 分⽀离开去新的分⽀有⼏个写法:暑假奇遇
1. git branch feature_print(或 git branch feature_print master ) && git checkout feature_print(或 git switch feature_print)
2. git checkout -b feature_print(或 git checkout -b feature_print master)
3. git switch -c feature_print (或 git switch -c feature_print master)
其中 git switch 是新版本的 git 命令，以前的章节讲过 git checkout ⽤来恢复⽂件，checkout 本⾝是签出⽂件的意思，⽤来切换分⽀语义上有点模糊，后连就增加了语义更加明确的 switch 切换，随时都可以使⽤ git branch 查看分⽀的情况，前⾯的 * 表⽰你当前所在的分⽀。
朝霞
wangbo@wangbo-VirtualBox:~/test/git-demo$ git branch* feature_print master
在新的分⽀下，可以专注于开发打印的功能了，我们添加⼀个 print.c ⽂件提交，从提交⽇志上看，⼯作成果是放到了feature_print 分⽀上。
如果想知道两个分⽀的变化，可以使⽤ git diff 分⽀1 分⽀2，⽐如输⼊ git diff master feature_print，由于我们当前就在feature_print 分⽀上，可以简化输⼊ git diff master 来和 master 分⽀相⽐较。
展开全⽂
可以⾮常清楚的看到了新增的打印相关的代码，假设打印的功能已经开发完成了，我们需要希望在主⼲分⽀上合并新的打印功能的代码，以便下⼀步的开发或是发布，⾸先切换到主分⽀:
1. git switch master
1. git switch master
2. git checkout master
wangbo@wangbo-VirtualBox:~/test/git-demo$ git switch masterSwitched to branch 'master'wangbo@wangbo-VirtualBox:~/test/git-demo$ git branch feature_print* master
git branch 命令清楚的显⽰当前已经在 master 主⼲分⽀了，现在需要将 feature_print 分⽀的代码合并到 master 分⽀上，怎么做呢? 有 2 种做法，我们分别来介绍。
第⼀种: 使⽤ git merge 指令，默认如果执⾏ git merge feature_print 就可以，但是这样不会为这次合并单独⽣成⼀个commit 节点，为了以后能清楚的看到分⽀合并的情况，通常会使⽤⼀个参数 --no-ff，也就是使⽤ git merge --no-ff feature_print 来执⾏。
合并完成以后，提⽰消息如下:
wangbo@wangbo-VirtualBox:~/test/git-demo$ git merge --no-ff feature_printMerge made by the 'recursive' strategy. print.c | 6 ++++++ 1 file changed, 6 inrtions(+) create mode 100644 print.c
通过 tig 看看分⽀时间线的形态，可以清楚的看到了，master 分⽀合并了 feature_print 分⽀的情况。
通常很多功能分⽀或者解决 bug 的分⽀，我们在合并完成以后，会将它删除，因为它的代码已经被合并到主分⽀了，以后需要继续开发或者有 bug 的话可以从主分⽀再次创建单独的分⽀来解决。使⽤ git branch -d feature_print 来删除打印功能的分⽀，使⽤ tig 查看⼀下分⽀时间线的形态，发现feature_print 分⽀这个名称不会再显⽰了，但是形态并没有变化，依靠提交的注释能够清楚的知道了合并了 feature_print 分⽀的代码。
分⽀的时间线形态⾮常重要，尤其是我们需要回到历史的时候，实际⼯作的时候，可能同时有多个分⽀存在，如果合并后的时间线形态杂乱⽆章，对我们代码的维护会产⽣⾮常⼤的副作⽤。
上⾯是理想的 merge 合并的情况，处于 master 分⽀和 feature_print 分⽀的代码完全是新增的包含关系，也就是没有修改到重叠的代码，如果合并feature_print 分⽀的时候，master 分⽀上的打印功能也被修改了，那么合并就会产⽣冲突，⽽ git merge 会直接合并⽂件，并且报告冲突的代码情况，这时候需要⼿动修改⽂件解决冲突，完成后再次做⼀次提交。如下图，master 和 feature_print 都同时修改了同⼀⾏代码，在 master 分⽀上查看区别:
执⾏ git merge --no-ff feature_print 后显⽰:
提⽰有冲突尝试⾃动合并，但是⾃动合并失败了(如果没有修改到重叠的代码 git 可以⾃动化的成功合并)，需要⼿动解决⽂件的差异了，因为 git 并不知道保留哪个分⽀的代码才是需要保留的，打开⽂件发现长这个样⼦，⽤ === 分割了 2 个分⽀的代码，使⽤ <<<< 表⽰当前⼯作分⽀， >>>> 表⽰了被合
并的 feature_print 分⽀。
铠怎么玩
我们觉得 master 分⽀添加的换⾏和 feature_print 分⽀的 ok ⽂本都是需要保留的，修改⽂件如下:
塑料瓶手工制作大全
使⽤ git status 查看⼀下仓库的状态:
wangbo@wangbo-VirtualBox:~/test/git-demo$ git statusOn branch masterYou have unmerged paths.如何消除焦虑心理
(fix conflicts and run "git commit") (u "git merge --abort" to abort the merge)Unmerged paths: (u "git add <file>..." to mark resolution) both modified: printo changes added to commit (u "git add" and/or "git commit -a")
显⽰ print.c 的⽂件状态是 both modified，需要暂存提交，执⾏ git add . && git commit -m 'fix print text' 后使⽤ tig 查看分⽀形态:
所以 git merge 的缺点就是有冲突的时候，所有⽂件都被合并了，没有给⽤户留机会做出选择，并且单独⽣成了⼀个合并的 commit 提交节点(显⽰ M)。如果希望渐进式的合并，就需要使⽤第⼆种⽅法。
第⼆种: 使⽤ git reba 命令，切换到 master 分⽀上，执⾏ git reba feature_print 合并，如果没有冲突，直接合并成功是最理想的情况，有冲突的情况如下:
git 给了我们三种选择:
1. ⾃⼰解决⽂件冲突后执⾏ git reba --continue 后继续尝试后⾯的合并
2. 执⾏ git reba --skip 直接跳过后继续尝试合并，回头再来收拾残局
3. 执⾏ git reba --abort 放弃本次合并，代码切换到 master 为合并前的状态
这时候我们可以打开⽂件 print.c，修复⽂件冲突，执⾏下⾯ 2 个命令继续合并:
git add .git reba --continue
continue 后 git 会继续尝试合并，如果还有⽂件冲突，重复执⾏这个过程，也可以随时 git reba --abort 放弃，不想⽴刻解决就执⾏ git reba --skip，直到整个合并完成。
wangbo@wangbo-VirtualBox:~/test/git-demo$ git statusreba in progress; onto 5a8323aYou are currently rebasing branch 'master' on '5a8323a'. (fix conflicts and then run "git reba --continue") (u "git reba --skip" to skip this patch) (u "git reba --abort" to check out the original branch)Unmerged paths: (u "git restore --staged <file>..." to unstage) (u "git add <file>..." to mark resolution) both modified: printo changes added to commit (u "git add"
unstage) (u "git add <file>..." to mark resolution) both modified: printo changes added to commit (u "git add" and/or "git commit -a")wangbo@wangbo-VirtualBox:~/test/git-demo$ git add .wangbo@wangbo-VirtualBox:~/test/git-demo$ git reba --continueApplying: add blank line
执⾏完成以后我们看看分⽀的时间线形态:
重点来了，我们发现 git reba 和 git merge ⽣成的时间线并不相同，merge 保留了提交历史和操作过程，reba 去掉了合并过程的提交更加简洁，但是合并后的 commit 信息可能需要修改，⽐如这个例⼦的 add blank line 已经不能同时表达⽂本被更新成 ok 的含义了，应该改为 fix print text 可能更合适(取决于你合并到底保留了什么样的代码)。
merge 和 reba 如何选择呢?
毕业论文参考
武松人物特点1. 如果需要⼀个⼲净的时间线形态选择 reba，如果希望渐进式的合并使⽤ reba，可能会需要更新⼀次 commit 信息。
2. 如果需要保留完整的历史记录使⽤ merge，有多个⽂件冲突的时候可能⽐较棘⼿，但是 commit 信息都会保留下来。关于 git 分⽀还有⼀些命令需要掌握:
1. 查看所有为合并的分⽀ git branch --no-merged
2. 查看合并过的分时 git branch --merged情人节的告白
3. 强⾏删除分⽀ git branch -D 分⽀名称
4. ⽽ git branch -v 可查看每个分⽀最后⼀次提交的情况
特别说明，⼀般我们不会在 master 分⽀上直接修改代码，本章节为了简化说明问题(避免太多的分⽀扰乱你的视线)，在master 上直接修改了代码，第 12 节学习科学的分⽀开发模型，也就是如何更加合理规范的使⽤ git 分⽀。
