很多时候，我们的软件开发都是“阶段性”的发布：
公司可能需要同时维护不同的版本，所以就会带来一系列的问题。比如：
咋办？
这时候就要引入分支，除了有1.0-2.0-3.0这样的“主干”代码，还要有1.1-1.2……这样的“分支”代码。
@想一想@：是不是只要留下1.0/2.0时候的代码副本就OK了？
不是的，1.1/1.2“分支”上面新增加的代码仍然是有用的，最终还是要合并到“主干”上的呀！
—— 这个过程被称之为merge，能够由版本控制工具自动完成。
注意：merge是“单向”的不是“同步”的，从release到master，只会将release上新提交的内容复制到master上，不会将master的内容复制到release。
branch还可以更主动、更广泛的用于并行开发：
git就默认采用了这种模式：
如果git要像svn一样，没有额外的branch，需要rebase（略）
PS：要不要各自独立branch的？
git能够把branch当做“基本功能”用（随随便便的开branch），主要还是因为她内部精妙的设计：
|
|
svn |
git |
|
开一个branch |
就“真”的copy了相关内容（演示） |
“假装”开了一个branch |
首先，每新建一个仓库，git会自动创建的一个master分支。（git至少需要一个分支）
我们通常会用该分支作为“主”分支：即大家共用的、主力维护着的分支。
但实际上，git中各个分支是“平等”的，master作为主分支只是约定俗成，没有什么特殊含义或强制性……
每一个分支，也有一个branch指针，新建分支实际上是创建一个新的branch指针。
每一个仓库，还有一个HEAD指针：默认指向（当前分支中的）最后一次提交
通过操作HEAD和branch指针，并配合checkout（更改/同步工作区内容），git就能实现一系列的功能！
PPT演示：（选修）
复习：本地和远程之间的sync是repository之间的同步。
但是，同步不是每次都把所有内容传一遍吧？
@想一想@：如何找到差异性的那一部分呢？
比如colon一个远程仓库到本地，那就会把整个仓库——包含其中的所有commit记录、branches和HEAD——完整的复制下来；反之亦然。
然后，额外记录下远程仓库中的branch，并把它们标记（添加前缀）为origin，比如：origin/master、origin/release……
#理解#：远程/origin分支存储在本地
本地保存着的远程分支不会随着commit而改变，除非fetch/pull。
在push之前，再更新一次远程branch，然后“对标”本地branch和远程branch（本地master对远程master；本地v1对远程v1……），将差异部分推送到远程。
版本号更多的时候用于打标签（tag），tag本质上和branch一样，只是名称不同。
branch除了用开发人员昵称命名，常见的还有：
常用的（以Github为例）有两种：
使用你选用的git插件，完成：
多快好省！前端后端，线上线下，名师精讲
更多了解 加：
