从0开始学习 GitHub 系列之「团队合做利器 Branch」

Git 相比于 SVN 最强大的一个地方就在于「分支」，Git 的分支操做简直不要太方便，而实际项目开发中团队合做最依赖的莫过于分支了，关于分支前面的系列也提到过，可是本篇会详细讲述什么是分支、分支的具体操做以及实际项目开发中究竟是怎么依赖分支来进行团队合做的。

1. 什么是分支？

我知道读者中确定有些人对分支这个概念比较模糊，其实大家能够这么理解，大家几我的一块儿去旅行，中间走到一个三岔口，每条路可能有不一样的风景，大家约定 3 天以后在某地汇聚，而后各自出发了。而这三条分叉路就能够理解成大家各自的分支，而等大家汇聚的时候至关于把大家的分支进行了合并。

2. 分支的经常使用操做

一般咱们默认都会有一个主分支叫 master ，下面咱们先来看下关于分支的一些基本操做：

• 新建一个叫 develop 的分支

git branch develop

这里稍微提醒下你们，新建分支的命令是基于当前所在分支的基础上进行的，即以上是基于 mater 分支新建了一个叫作 develop 的分支，此时 develop 分支跟 master 分支的内容彻底同样。若是你有 A、B、C三个分支，三个分支是三位同窗的，各分支内容不同，若是你当前是在 B 分支，若是执行新建分支命令，则新建的分支内容跟 B 分支是同样的，同理若是当前所在是 C 分支，那就是基于 C 分支基础上新建的分支。

• 切换到 develop 分支

  git checkout develop

• 若是把以上两步合并，即新建而且自动切换到 develop 分支：

git checkout -b develop

• 把 develop 分支推送到远程仓库

  git push origin develop

• 若是你远程的分支想取名叫 develop2 ，那执行如下代码：

  git push origin develop:develop2

可是强烈不建议这样，这会致使很混乱，很难管理，因此建议本地分支跟远程分支名要保持一致。

• 查看本地分支列表

  git branch

• 查看远程分支列表

  git branch -r

• 删除本地分支

  git branch -d develop

  git branch -D develop (强制删除)

• 删除远程分支

  git push origin :develop

• 若是远程分支有个 develop ，而本地没有，你想把远程的 develop 分支迁到本地：

  git checkout develop origin/develop

• 一样的把远程分支迁到本地顺便切换到该分支：

  git checkout -b develop origin/develop

3. 基本的团队协做流程

通常来讲，若是你是一我的开发，可能只须要 master、develop 两个分支就 ok 了，平时开发在 develop 分支进行，开发完成以后，发布以前合并到 master 分支，这个流程没啥大问题。

若是你是 三、5 我的，那就不同了，有人说也没多大问题啊，直接能够新建 A、B、C 三我的的分支啊，每人各自开发各自的分支，而后开发完成以后再逐步合并到 master 分支。然而现实倒是，你正在某个分支开发某个功能呢，这时候忽然发现线上有一个很严重的 bug ，不得不停下手头的工做优先处理 bug ，并且不少时候多人协做下若是没有一个规范，很容易产生问题，因此多人协做下的分支管理规范很重要，就跟代码规范同样重要，如下就跟你们推荐一种咱们内部在使用的一种分支管理流程 Git Flow。

4. Git Flow

准确的说 Git Flow 是一种比较成熟的分支管理流程，咱们先看一张图能清晰的描述他整个的工做流程：

第一次看上面那个图是否是一脸懵逼？跟我当时同样，不急，我来用简单的话给大家解释下。

通常开发来讲，大部分状况下都会拥有两个分支 master 和 develop，他们的职责分别是：

• master：永远处在即将发布(production-ready)状态

• develop：最新的开发状态

确切的说 master、develop 分支大部分状况下都会保持一致，只有在上线前的测试阶段 develop 比 master 的代码要多，一旦测试没问题，准备发布了，这时候会将 develop 合并到 master 上。

可是咱们发布以后又会进行下一版本的功能开发，开发中间可能又会遇到须要紧急修复 bug ，一个功能开发完成以后忽然需求变更了等状况，因此 Git Flow 除了以上 master 和 develop 两个主要分支之外，还提出了如下三个辅助分支：

• feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop

• release: 准备要发布版本的分支, 用来修复 bug，基于 develop，完成后 merge 回 develop 和 master

• hotfix: 修复 master 上的问题, 等不及 release 版本就必须立刻上线. 基于 master, 完成后 merge 回 master 和 develop

什么意思呢？

举个例子，假设咱们已经有 master 和 develop 两个分支了，这个时候咱们准备作一个功能 A，第一步咱们要作的，就是基于 develop 分支新建个分支：

git branch feature/A

看到了吧，其实就是一个规范，规定了全部开发的功能分支都以 feature 为前缀。

可是这个时候作着作着发现线上有一个紧急的 bug 须要修复，那赶忙停下手头的工做，马上切换到 master 分支，而后再此基础上新建一个分支：

git branch hotfix/B

表明新建了一个紧急修复分支，修复完成以后直接合并到 develop 和 master ，而后发布。

而后再切回咱们的 feature/A 分支继续着咱们的开发，若是开发完了，那么合并回 develop 分支，而后在 develop 分支属于测试环境，跟后端对接而且测试的差很少了，感受能够发布到正式环境了，这个时候再新建一个 release 分支：

git branch release/1.0

这个时候全部的 api、数据等都是正式环境，而后在这个分支上进行最后的测试，发现 bug 直接进行修改，直到测试 ok 达到了发布的标准，最后把该分支合并到 develop 和 master 而后进行发布。

以上就是 Git Flow 的概念与大概流程，看起来很复杂，可是对于人数比较多的团队协做现实开发中确实会遇到这么复杂的状况，是目前很流行的一套分支管理流程，可是有人会问每次都要各类操做，合并来合并去，有点麻烦，哈哈，这点 Git Flow 早就想到了，为此还专门推出了一个 Git Flow 的工具，而且是开源的：

GitHub 开源地址：https://github.com/nvie/gitflow

简单点来讲，就是这个工具帮咱们省下了不少步骤，好比咱们当前处于 master 分支，若是想要开发一个新的功能，第一步切换到 develop 分支，第二步新建一个以 feature 开头的分支名，有了 Git Flow 直接以下操做完成了：

git flow feature start A

这个分支完成以后，须要合并到 develop 分支，然而直接进行以下操做就行：

git flow feature finish A

若是是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支。

想必你们已经了解了这个工具的具体做用，具体安装与用法我就很少提了，感兴趣的能够看我下我以前写过的一篇博客：

http://stormzhang.com/git/2014/01/29/git-flow/

5. 总结

以上就是我分享给大家的关于分支的全部知识，一我的你也许感觉不到什么，可是实际工做中大都以团队协做为主，而分支是团队协做必备技能，而 Git Flow 是我推荐给大家的一个很流行的分支管理流程，也是咱们薄荷团队内部一直在实践的一套流程，但愿对大家有借鉴意义。