gitlab-flow分支模型
1 分支模型
参考阮一峰的教程
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 gitlab.com 推荐的做法。
1.1 上游优先
Gitlab flow 的最大原则叫做"上游优先"(upsteam first)，即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
Chromium项目就是一个例子，它明确规定，上游分支依次为：
1. Linus Torvalds的分支 2. 子系统（比如netdev）的分支 3. 设备厂商（比如三星）的分支
1.2 持续发布
Gitlab flow 分成两种情况，适应不同的开发流程。对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
1.3 版本发布
对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如v2.3-stable、v2.4-stable等等。以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
团队协作开发时，一般都是基于master分支进行，也就是rebase操作时的基准为master，并且提交合并请求时的目标分支也为master
next分支：下一个稳定分支，可能存在一些bug，当前团队会有部分为基于此分支进行开发。
版本规范参考: 语义版本规范
2 git开发流程
团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。
否则，每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。
2.1 fork要参与开发的仓库(repository)
2.2 clone仓库到本地
# 克隆仓库到本地，默认会添加一个名为origin的远程仓库
git clone ssh://...
2.3 新建分支
首先，每次开发新功能，都应该新建一个单独的分支（这方面可以参考《Git分支管理策略》）。
# 获取origin最新代码
git fetch origin
git checkout origin/master
# 新建一个开发分支myfeature(名字根据需求来定，如bugfix/a)
git checkout -b myfeature
2.4 提交分支commit
分支修改后，就可以提交commit了。具体可以参考 02_cheatlist.md
git add .
git status
# 查看变更
git diff
# 提交变更
git commit
2.5 与主干同步
分支的开发过程中，要经常与主干保持同步。
# git pull是git fetch和git merge两个步骤的结合, 图中第5步应该为git fetch
git fetch origin master
# 首先，git 会把 myfeature 分支里面的每个 commit 取消掉；
# 其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
# 然后，把 myfeature 分支更新到最新的 master 分支；
# 最后，把上面保存的 patch 文件应用到 myfeature 分支上
git rebase -i origin/master
更加简化的指令为
git pull --rebase origin master
分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。
那么，怎样才能将多个commit合并呢？这就要用到 git rebase 命令。参考git rebase说明
git rebase -i origin/master
git rebase命令的-i参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。
squash和fixup命令，还可以当作命令行参数使用，自动合并commit。
git commit --fixup git rebase -i --autosquash
这个用法请参考这篇文章，这里就不解释了。
2.6 推送到远程仓库
合并commit后，就可以推送当前分支到你自己的远程仓库了。
git push -u origin myfeature
2.7 发出Merge Request
提交到远程仓库以后，就可以发出 Merge Request 到主干分支，即master分支或者next分支，然后请求别人进行代码review，确认可以合并到master。
2.8 同步bug-fix提交到其他稳定分支
git fetch origin
git checkout origin/vx.y-stable
git cherry-pick <commit-id> # commit-id 为 master 或 next 等上游分支上的 commit
# 解决冲突
# 提交到远程，主要由于 vx.y-stable 分支为受保护的分支，无法直接提交，因此需要重新定义远程分支名字， fix-xxxx 可以随便取，只要不冲突即可
git push origin vx.y-stable:fix-xxxx
# 提交合并请求到 vx.y-stable 分支
# 重复以上步骤，将新的bug修复commit合并到其他稳定版本分支