首先列一下我所看到的git分支管理：
市面上常见的分支管理方式
其中：中间的Origin代表的是远程分支，Native代表的是程序猿自己本地的分支。
这种常见的分支管理方式很普遍，但是同样，我认为也没有用到点上，是处于最低端的，git的用法可不仅仅在于这些。
首先，我先绘制一下我所说的相对标准的git分支管理方案：
相对标准的分支方案
接下来我会以腾讯工蜂系统对以上步骤详细解读一下(Origin代表的依旧是远程分支，Native代表的依旧是程序猿自己本地的分支)：
- 步骤1:基于master检出远程分支的dev.1.0分支,这个dev.1.0为1.0版本的总分支（这个比较简单，略过）
- 步骤2：主管对远程分支的dev.1.0进行加锁，如下图：
腾讯工蜂系统某一分支页面
其中：点击左1红色框可选择某一远程分支，左2红色框为当前的分支（dev.1.6.2），左3红色框为加锁按钮。
点击左3红色框的加锁，可以看到：
加锁的描述
点击底部绿色“创建锁”即为创建锁成功。（看下上图对于锁的描述与目的，这是很重要的思想）
-
步骤3：基于远程分支的1.0总分支，创建属于自己的远程分支，之前的规则为dev.1.0.程序猿名字简写或全拼
-
步骤4：团队下的程序猿将自己的远程检出到本地
-
步骤5：提交自己代码到远程分支（直接push，没必要执行pull等操作）
-
步骤6：因为步骤2加锁的缘故，并不是所有人都有对dev.1.0的修改权限，所以在git地址上，创建一个merge请求，目的是将自己远程分支上的代码合并到dev.1.0这个版本总分支上，同时艾特同组人员进行代码审核，如下图：
创建merge请求页面
点击左侧红色框，后再点击右侧红色框，则如下图：
选择源分支和目的分支(注：当前是以dev.1.7.0.lc为源分支，目的分支是dev.1.5,忽略这个细节）
点击左下角的“比较两分支”，若有未merge的代码，则会跳转到如下页面（这个页面数据较多，以下三张图片连起来则为当前页面的全部功能）：
图片1：填写标题，描述以及选择代码评审人，评审人为同组开发者，必要评审人为主管
图片2：选择评审人通过规则，只有达到设置的评审规则，后续主管才能合并代码（评审代码在下图）
图片3：确认源分支和目标分支，并选择是否创建新的分支，以及底部红色框的两个按钮分别为：提交记录与代码变更
鉴于代码安全方面的考虑，就不截图代码“变更”记录了。
- 步骤7：在Origin:dev.1.0分支上打包，提交审核之后，苹果审核通过之后，Origin:dev.1.0再创建一个merge请求（参考步骤6），将Origin:dev.1.0代码合并到master。这一步骤是为了防止审核不通过，导致master代码与app store的功能不一致。
最后说下这套分支方案的优点：
-
高效性。很多人会疑问：这套方案看起来复杂，哪来的高效性？其实不然。原因在于步骤3和步骤4的存在，我只关心我自己的功能，其他人提交了什么我不管。如果按照文章开始的那套分支方案，其他人提交了代码，我在提交时，大概率上还要拉取远程分支，最终会导致再次编译，这点我是难以忍受。项目大了，人员多了，耗费的时间会翻倍增长。
-
流程规范。包含了git相关的所有功能，比如远程分支，本地分支，pull，push，merge等。
-
安全性。安全性包含了两方面：1.步骤2的远程分支的加锁。2.步骤5的本地分支代码的随时提交，比如中午吃饭，抽烟，开会，下班等出现离开电脑前的情况时，随时将本地代码push到自己的远程分支，保证本地分支的代码与远程分支始终保持一致，即使是功能未完成，跑不起来也要提交，提交之后也不会影响其他人编译他们自己的分支上的代码。
当然，正如文章标题所说，这套分支方案是相对标准，有一定缺陷。随着知识点的增加与编程思想的夯实，我心目中也有一套绝对标准的分支管理方案，后续有时间我会更新。
网友评论