Git分支管理策略【转】

摘录自：
http://www.ruanyifeng.com/blog/2012/07/git.html

所有的版本管理工具都没有想象中无所不能，需要管理规则来约束才可以让管理思路更清晰，也不至于项目失控。目前项目组使用git来管理代码，所以整理一下。

一、主分支Master

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布（但不绝对哈）。

项目组的实际情况：
1）所有开发工作都不会在这个分支上进行
2）版本标签是在这个分支上打的，我们选择打标签的时机是，在每次发布新的常规版本的时候对上一个版本进行打标签操作。
3）为了让配置文件更好管理，项目组并没有把Master作为发布分支，而是新增了一个release分支用于发布。一些特殊的配置文件只有这个分支上有，其他分支上是没有的（通过.gitignore来管理）。但是其实也是有麻烦的，譬如涉及都密码的信息不得不放在release上，所有人下载代码之后是可视的。这个就得考虑这个项目的密码信息的密级，如果密级非常高，还是不要这样做比较妥当。同时，加多了release分支，在发布代码的时候两个分支的代码都要去更新，也会增加工作量。
4）master分支被用成了一个预发布分支，本地合并校验是否代码有冲突，和校验功能是否正常。

二、开发分支Develop

主分支master只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

Git创建Develop分支的命令：

git checkout -b develop master

将Develop分支发布到Master分支的命令：

    # 切换到Master分支
　　git checkout master
　　# 对Develop分支进行合并
　　git merge --no-ff develop

备注：默认情况下，Git执行”快进式合并”（fast-farward merge），会直接将Master分支指向Develop分支。使用–no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。

项目组的实际情况：
1）在实际管理过程中，也常常用系统名称加版本号来作为分支名。这样好认些。
2）通常分支的新建、获取、合并都在工具里完成，所以我平时也没怎么关注这些参数是否有添加。

三、临时性分支

前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

    * 功能（feature）分支
    * 预发布（release）分支
    * 修补bug（fixbug）分支

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

项目组的实际情况：
1）这些分支都是常设分支，项目组是小团队管理，而且业务刚开始开展，实际上可能每天都有一些小调整发布到正式环境，所以fixedBug分支是我们的常设分支，如果有需要，每天下午5点会定时发布。

四、 功能分支

第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

创建一个功能分支：

git checkout -b feature-x develop

开发完成后，将功能分支合并到develop分支：

git checkout develop
git merge --no-ff feature-x

删除feature分支：

git branch -d feature-x

项目组的实际情况：
1）项目组的dev分支是基于版本号来建立的，没有直接使用develop来命名。进行得也比较有序。

五、预发布分支

跳过预发布分支，因为我们的预发布分支是master。

六、修补bug分支

软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。

创建一个修补bug分支：

git checkout -b fixbug-0.1 master

修补结束后，合并到master分支：

git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

再合并到develop分支：

git checkout develop
git merge --no-ff fixbug-0.1

最后，删除”修补bug分支”：

git branch -d fixbug-0.1

项目组的实际情况：
1）fixedBug分支基本是不删除的，但是时刻也要跟master保持最新合并状态。