命名
- 分支命名规则
- master：同步线上AppStore 代码。每次发版完毕，会往这里合。
- develop：当前开发代码。
- develop10.0.1：10.0.1为当前开发版本，可有可没有。(有人喜欢针对当前版本新建一个分支,建议发版以后merge入develop删除,留下tag即可)。
- develop_damao：大毛的开发分支，平时只允许在这个分支上push。
- develop_ermaoming：二毛的开发分支。
- . hotfix10.0.2：如果10.0.1线上崩溃，需要紧急修复，则创建一个以新版本号命名的分支。
- tag 命名规则
- AppStore10.0.2：某版本线上包对应的tag号，可以在发版后标记。
- 0.15.2：平时打随意，保证三段即可。
场景
三人合作开发一个app，老大叫大毛，老二叫二毛，老三叫三毛。 这时候大毛去gitlab开一个repository,开了如下分支
- develop
- develop_damao
- develop_ermao
- develop_sanmao
OK,现在大毛告诉，二毛和三毛，去clone 吧。clone 下来以后
二毛本地的分支只有一个
- master
现在让他们分别从远程拉两个分支，分别是develop 和develop_ermao，那么二毛本地的分支就是
- master
- develop
- develop_ermao
好了，接下来开始干活了，为了避免出现conflict 和污染主分支，做到以下几点就，一般不会出现问题
- 做好分工，避免多人改同一个文件
- 二毛只会在二毛自己的develop_ermao进行开发
- 二毛只在自己的分支push
- 如果想合并，按照如下流程（敲黑板，划重点）
- git pull –all #为了pull develop分支，不知道什么命令可以在pull 别的单个分支
- git merge develop #合并最新的开发分支，有冲突改冲突
- 切换到develop ，merge develop_ermao ，push develop # 因为上一步刚刚已经merge 过新鲜的develop 了，所以这一步肯定是fast-forword merge，不会有冲突
- 每完成一个功能点，提交一次。
这样的流程有什么好处呢？
- 几乎不会出现conflict
- 永远不会污染别人的分支，公共的分支。因为即使出现冲突，也是在自己的分支内解决。
- 如果点儿背，在电光火石的操作过程中，别人恰好提了一个到develop，以为新鲜的develop其实已经过期了。在 git push develop 的时候冲突了。提不上去。莫慌，这时候执行一下 git pull –rebase ，然后重新git push就可以了。
- 开发的时候，本地只需要两个分支，develop ，develop_ermao
- 每个人都可以直接push自己的分支，设计到公共的分支，必须先pull ，merge develop，merge 回develop，push。
- 如果说工程里面，有develop10.0.1这种针对当前版本的分支，那么二毛三毛不用操心，就是大毛辛苦一点，每次新版本开始都先创建好一个新分支develop10.0.1，然后二毛，三毛直接在develop10.0.1操作。当版本结束以后，大毛再并入develop。
整体思路
主要采用Long-Running Branches（master，develop） 的工作流，结合一部分Topic Branches（develop_damao,develop_ermao,develop_sanmao）。 参考书籍章节Git-Branching-Branching-Workflows
渐进稳定分支的线性图
参考
- iOS开发中的Git流程 叶孤城___ 2015-10-20 10:35
