Git分支管理

理解分支

分⽀就是科幻电影里面的平行宇宙，当你正在电脑前努力学习C++的时候，另⼀个你正在另⼀个平行宇宙里努力学习JAVA。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并 了，结果，你既学会了C++也学会了JAVA。

在版本回退里，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截止到目前，只有⼀条时间线，在Git里面，这个分支叫主分支，即master分支。

再来理解⼀下HEAD，HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

同样的，我们可以创建出分支，最后合并分支到主分支上。 

创建分支

HEAD可以执行其它分支，不一定是只指向master分支，而被HEAD指向的分支便是当前的工作分支。当前的HEAD指向的是master分支。

使用git branch [name]来创建分支。

使用git branch查看到当前的分支。

创建处理的分支，是站在当前最新的提交记录上的，因此，新建出来的分支，与master分支的最新提交记录的一模一样的。

可以使用cat .git/refs/heads/master查看 

创建好新分支后，想要在新分支上工作，则将HEAD指向该新分支。

切换分支

使用git checkout dev进行切换分支。注意与撤销修改命令git checkout -- file区别开

此时，对工作区中的文件进行修改，使用这个分支！

接着，为了验证，切换回master分支，来看看，这个修改记录存在不：

 此时，master和dev两个分支的提交记录已经不一样了：

此时的状态是这样的：

当切换到master分支之时，HEAD就指向了master，当然看不到提交了。

创建分支有两种方式： 除了上面介绍的：①git branch dev。②git checkout dev。通过两步来创建并切换分支。还有一步到位，创建并切换的：git checkout -b dev

合并分支

为了在master上也能看到最新记录，就就需要将dev分支合并到master分支上。

git merge 命令用于合并指定分支到当前分支。合并后，master就能看到dev分支提交的内容 了。此时的状态如图如下所示：

合并的步骤是：

①切换到需要合并的分支上，也就是master分支。

②使用git merge dev。将dev分支合并到master分支上。

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

此时可以看到，合并了：

接着，查看master提交记录，发现，它更新了，变成了dev的提交记录，也就是最新的提交记录了。

删除分支 

合并完成后,dev分支对于我们来说就没用了，那么dev分支就可以被删除掉，注意如果当前正处于某分支下，就不能删除当前分支。

使用  git branch -d [name] 将分支删掉。

合并冲突

出现的问题

当在master分支在对文件内容进行修改的同时，在dev也对文件内容的同一行同一个位置进行修改，两个分支修改的内容均不同。比如文件ReadMe第三行原本的内容是aaa，masert分支将其改成bbb，dev分支将其改成ccc，接着在对master和dev进行合并时，git将保存谁呢？这就是合并冲突问题。

切换到master分支，进行合并：发现合并冲突，提醒需要修改文件内容并重新提交 

 打开ReadMe文件，发现出现了两个分支的最新提交的内容。

解决合并冲突问题

 在合并后，git会在文件上显示两个分支提交的内容，此时我们可以自己手动选择要保留的内容，保存后。重新add和commit便可。

此时的状态是：

此时，master指向的是最新提交，dev指向的是自己的最新的提交。

可以通过git log查看合并情况：

合并模式

在合并分支后，git会采用Fast forward模式，在这个模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是merge进来的还是正常提交的。

而在合并冲突后，发现Fast forward模式不在了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到master其实是由其他分支合并得到。

如果想要正常合并也能看到分支信息，可以在合并时，在merge后加上--no-ff ，表示禁止是否fast forward模式；

git merge --no-ff -m "merge with no-ff" dev2

请注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

bug分支

场景：如果在dev2分支的开发的过程中，发现之前提交给master分支的代码出现了bug，需要去解决。但是dev2是作为开发分支的，那么此时需要额外多创建一个临时的分支，专门用于修复bug。

可是，在dev2中正在开发的代码在工作区中，并没有提交，如果此时切换到master分支，创新新的分支去修复bug，那么在dev2工作区的代码也会显示出来。

[wjmhlh@VM-12-9-centos gitcode]$ git branch
* dev2
master
[wjmhlh@VM-12-9-centos gitcode]$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ...
[wjmhlh@VM-12-9-centos gitcode]$ git status
On branch dev2
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

此时需要用到git stash命令。

git stash命令可以将可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。这样，就可以放心地去创建一个临时的分支去修改bug了。

储藏 dev2 工作区之后，由于我们要基于master分支修复bug，所以需要切回 master 分支，再新 建临时分支来修复bug，实例如下：

[wjmhlh@VM-12-9-centos gitcode]$ git checkout master       # 切回master
Switched to branch 'master'
[wjmhlh@VM-12-9-centos gitcode]$ git checkout -b fix_bug   # 新建并切换到 fix_bug 分⽀
Switched to a new branch 'fix_bug'
[wjmhlh@VM-12-9-centos gitcode]$ vim ReadMe
[wjmhlh@VM-12-9-centos gitcode]$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e                                                # 修复bug--忘记写e
[wjmhlh@VM-12-9-centos gitcode]$ git add ReadMe            # 重新add，commit
[wjmhlh@VM-12-9-centos gitcode]$ git commit -m"fix bug"
[fix_bug 4bbc0c4] fix bug
1 file changed, 1 insertion(+), 1 deletion(-)

 修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支。到此，bug修复完毕，重新回到dev2上进行工作。在工作前，将原本正在开发的代码从存储区中拿回来：

使用 git stash pop 命令，恢复的同时会把stash也删掉。当然，在拿回来前，可以查看存储区有没有可以恢复的内容现场：⽤ git stash list 命令看看。

除此之外：恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要 用 git stash drop 来删除；你可以多次stash，恢复的时候，先用 git stash list 查看，然后恢复指定的stash，⽤命令git stash apply stash@{0}

代码开发完成后，可以提交了。但是，必须记得，在上面修复好的bug，并没有在dev2中修复，如果此时直接合并到master中，会导致合并冲突，要在master分支中人工去改，这很可能会导致新bug的出现。

因此，在合并前，最后在dev2分支上，将master合并进来，然后修复bug。修复后，进入master分支，将dev2合并到master上。

总结步骤就是：

①发现之前提交给master的代码出现了bug。

②使用stash，将工作区的代码存储起来。

③进入master分支，创新临时分支去修复bug。

④修复后， 合并到master分支上。

⑤回到dev2分支，将存储起来的代码拿回来，继续开发。

⑥开发完毕，将master合并过来，修复bug。

⑦修复完成，将最终的dev2合并到master中。

强制删除分支

如果在某个分支上进行开发，并且已经提交了一部分的代码了，但是此时由于某些原因，这个分支的代码不要了，需要删除这个分支。在git看来，如果这个分支已经commit提交了代码，说明是有用的，不能随意被删除，也就是不能使用git branch -d [name]删除。此时，可以将d改成D，表示强制删除。