git分支管理策略 - mindpin/knowledge-space-net-lib GitHub Wiki

基于产品环境与测试环境部署中的说明，4ye.me 客户端的将分为评估版本和正式运营版本来发布。两个版本分别具有如下特性：

评估版本：
主要用于给人私下演示，探讨新功能可行性，测试新体验等一些用途。突出给人展示，观看的方面。
不特别要求逻辑的完整健壮性，甚至不特别要求数据的正确性；
同时，评估版通常不要求版本前后的一致性，比如可能在 x.x.1 版本里加入了某功能/体验场景，而在 x.x.2 里又拿掉。

正式运营版本 用来给真正的最终用户使用，给最终用户带来稳定的内容和持续平滑的功能体验更新。
严格要求逻辑的完整健壮性，严格要求数据的正确性；
正式运营版本的前后一致性要做到平滑，功能的添加和删减都会十分谨慎。

基于以上描述，评估版本和正式运营版本代码会差异很大。需要对之前的代码发布策略做出一定的调整。

将某个commit置于master分支，并打上tag，称为发布
而将某个代码状态通过上传脚本提交到版本号服务，在此文中称为推送
这两个操作需要独立来看。

对于版本库 https://github.com/mindpin/eshare-android-preview
在 2014.02.17 之后，删除除 master 和 develop 之外的所有其他分支。
并确保 master 和 develop 已经都达到了最新代码状态。（commit 177ea0d8）
保留三个 tag 0.1.1 0.1.2 和 0.1.3

分支的管理基于 workflow 管理策略，参考：
http://nvie.com/posts/a-successful-git-branching-model/ http://blog.jobbole.com/23398/

用于正式运营版本的发布。同时作为版本库的主分支。
需要严格保证该分支上每一个 commit 都对应一个正式运营版本号，同时对应一个tag。
!! 不允许master分支上出现其他commit !! 如果错误提交，必须第一时间删除 commit
这个分支通常只会进行正式运营版本的发布。

用于平时的开发工作，大家的本地版本库通常都 checkout 到这个分支。

为了开发某种功能，从 develop 上分出来一个分支 以 'feature-xxx'命名
开发完毕后，合并回 develop 分支

# 创建一个功能分支：
git checkout -b feature-xxx develop

# 开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge –no-ff feature-xxx

# 删除feature分支：
git branch -d feature-xxx

注意，这里的分支合并回 develop 分支，必须使用 -no-ff 参数，理由参考：
http://blog.jobbole.com/23398/ 中的说明

为了进行某个版本的发布，创建的分支。很多时候，我们准备发布一个新版本，但是肯定无法做到立刻提交完全正确的代码到 master，这时，就可以创建一个 release-xxx 分支来进行预发布，通过若干个commit做到代码正确，再合并到 master 分支。

# 创建一个预发布分支：
git checkout -b release-1.2 develop

# 确认没有问题后，合并到master分支：
git checkout master
git merge –no-ff release-1.2

# 对合并生成的新节点，做一个标签
git tag -a 1.2

再合并到develop分支：
git checkout develop
git merge –no-ff release-1.2

最后，删除预发布分支：
git branch -d release-1.2

当master上正式发布了某个版本后，有时又发现了新的bug，则需要创建一个 fixbug 分支对其进行修正。
比如在 0.1 发现bug，则创建一个 fixbug-0.1 分支，经历若干个 commit 修正bug后，合并回 master 并打一个新的tag 0.1.1
之后推送到发布服务器

创建一个修补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

总体来说也可以参考这张图：

当需要发布一个评估版本时：
例如，想加入一种新的课程形式，但不适合正式发布，可以做评估版本。
想修改或加入一些视觉体验，有人急着要看，但不适合正式发布，可以做评估版本。

当需要开发一个评估版本时，从 develop 创建一个评估分支 evaluation-xxx
经过若干个commit之后，在该分支上直接推送评估版本。

创建一个评估分支：
git checkout -b evaluation-xxx develop

开发结束后，直接推送到服务器。该分支视情况保留或删除。**不一定会合并回develop分支**

有时为了方便起见，也可能会在 develop 或者 feature-xxx 分支上推送评估版本。总之比较随便一些
评估版本不用保证版本的持续连贯性，0.2.1 版无法平滑升级到 0.2.2 版也没有关系。因为主要是给人演示用，经常是要的时候催的很急，但是用完即扔。