Git 学习笔记 - 11 - 创建与合并分支

注：本文参照的是廖雪峰老师的Git教程

概念：

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

这时你可以创建一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

ps：虽然工作上用的是SVN，但是总体而言，每次都是搞定之后上传到的，没用过分支…

理解：

第一遍粗略的看了一下分支这个概念，发现有点晕，细看了一下之后原来就这么一回事：

之前确认一件事：我们说过 Git 有一个master 分支，这个分支其实就是主分支。

首先我们将 Git 想象成一颗树，将master分支想象成主枝干，所有人连接的都是这个枝干上面，
现在呢你想创建一个私有的枝干来保存你的代码，在你和主枝干同步的地方衍生出一根树枝，这个树枝存储了你的代码，别人不会连接上来，别人如果也想要连接一条私有枝干的话就会重新衍生一条专门属于他的，不会影响到你这。
当你修改好了之后，你觉得可以推送到主枝干上去了之后，就相当于把你这个私有的枝干发育强壮，变成了主枝干的延伸，也就是将master 分支改变到你的这个分支上来，后面再查看的话都可以看到你的修改了。
这时很多情况下都会有多个私有分支想将他修改的内容提交到主分支上去，如果你们修改的内容不相互影响，没有问题，都会综合进去，如果有问题，就会冲突，
如何解决冲突，下节练习。

练习分支的创建与合并

创建一个分支
```
git checkout -b 分支名
```
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
```
$ git branch 分支名
$ git checkout 分支名
```
查看当前分支
```
git branch
```
分支前面带有 * 号，表示当前所处的分支，

master 为主分支。
在刚刚建好的分支下修改文件
```
vi readme.txt
```
进入后按 i 开始修改，修改完后 :wq 保存并退出。
查询一下状态

使用 git status 命令查看当前的文件状态，发现 readme.txt 文件已被修改，但是还没有提交。
将修改后的 readme.txt 文件添加进 Git 管理。
然后将 readme.txt 文件提交到 Git 仓库，完成修改。
再次使用 git status 命令查看当前的文件状态，发现文件已经提交
现在我们切回到master分支
```
git checkout master
```
使用 cat 命令查看一下 readme.txt 文件

发现还是之前没有修改的样子，这是因为修改是在分支 dev 上执行的，并没有影响到master 分支上来。
将指定分支合并到当前分支上来
```
git merge 指定分支名
```
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
完成后，dev分支再无其他用处，所有先删除这个分支
```
git branch -d 分支名
```
再次查看分支

发现只剩下了master分支。

分支的创建与合并

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

总结：

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

创建+切换分支：git checkout -b <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>