Git团队合作利器: branch

Git 相比于 SVN 最强大的一个地方就在于「分支」。实际项目开发中的团队合作，以及一人多台电脑的项目维护中，最依赖的莫过于分支了。本篇会详细讲述什么是分支、分支的具体操作以及实际项目开发中到底是怎么依赖分支来进行团队合作的。

1.什么是分支？

简单理解一下，几个人一起去旅行，中间走到一个三岔口，每条路都有不同的风景，这三条分叉路即是各自的分支。3 天之后在某地汇聚时，则相当于对分支进行了合并。

2.分支的常用操作

通常我们默认都会有一个主分支叫 master ，下面我们先来看下关于分支的一些基本操作：

• git branch develop 新建一个叫 develop 的分支
  Note: 新建分支基于当前所在分支，即以上是基于 mater 分支新建了的 develop分支，此时 develop 分支跟 master 分支的内容完全一样。如果你有 A、B、C三个分支，三个分支是三位同学的，各分支内容不一样，如果你当前是在 B 分支，如果执行新建分支命令，则新建的分支内容跟 B 分支是一样的。

• git checkout develop 切换到 develop 分支

• git checkout -b develop 新建并且自动切换到 develop 分支（以上两步合二为一）

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

• git push origin develop:develop2 分支重命名为develop2
  但是最好不要这样，强烈建议本地分支跟远程分支名要保持一致，否则很难管理。

• git branch 查看本地分支列表

• git branch -r 查看远程分支列表

• git branch -d develop 删除本地分支

• git branch -D develop (强制删除)

• git push origin :develop 删除远程分支

• git checkout develop origin/develop 把远程的 develop 分支迁到本地（远程分支有个 develop ，而本地没有）

• git checkout -b develop origin/develop 把远程分支迁到本地并切换到该分支

3.基本的团队协作流程

一般来说，如果是一个人开发，可能只需要 master、develop 两个分支，平时开发在 develop 分支进行，开发完成之后，发布之前合并到 master 分支。
如果是多个开发，分支管理规范尤其重要，和代码规范一样重要，以下推荐一种分支管理流程 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

Git Flow 还专门推出了一个 开源的Git Flow 的工具。这个工具帮我们省下了很多步骤，比如我们当前处于 master 分支，如果想要开发一个新的功能，第一步切换到 develop 分支，第二步新建一个以 feature 开头的分支名，有了 Git Flow 直接如下操作完成了：
git flow feature start A

这个分支完成之后，需要合并到 develop 分支，然而直接进行如下操作就行：
git flow feature finish A

如果是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支。
具体安装与用法如下：
A successful Git branching model

作者还提供了 git-flow 命令工具: git flow init

接着它会问你一系列的问题，尽量使用它的默认值就好了：
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for “next release” development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始:
git flow feature start some_awesome_feature

完成功能开发之后:
git flow feature finish some_awesome_feature

该命令将会把feature/some_awesome_feature合并到develope分支，然后删除功能(feature)分支。

将一个 feature 分支推到远程服务器:
git flow feature publish some_awesome_feature
或者
git push origin feature/some_awesome_feature

当你的功能点都完成时（需要发布新版本了），就基于develop创建一个发布(release)分支，然后升级版本号并在最后发布日期前把Bug Fix掉吧：
$ git flow release start v0.1.0

当你在完成（finish)一个发布分支时，它会把你所作的修改合并到master分支，同时合并回develop分支，所以，你不需要担心你的master分支比develop分支更加超前。

最后一件让git-flow显得威武的事情是它处理热修复（即时的BugFix）的能力，你可以像其他分支一样地创建和完成一个热修复分支，区别是它基于master分支，因此你可以在产品出现问题时快速修复，然后通过”finish”命令把修改合并回master和develop分支。

参考：
git-flow 的工作流程
GitHub 系列之「团队合作利器 Branch」