成为VIP
前言
高效的持续交付体系，必定需要一个合适的代码分支策略。采用不同的代码分支策略，意味着实施不同的代码集成与发布流程，这会影响整个研发团队每日的协作方式，因此研发团队通常需要很认真地选择自己的策略。
主干开发（TBD）
主干开发是一个源代码控制的分支模型，开发者在一个称为 “trunk” 的分支（Git 称 master）中对代码进行协作，除了发布分支外没有其他开发分支。
Google 和 Facebook 都是采用“主干开发”的方法,代码一般直接提交到主干的头部，这样可以保证所有用户看到的都是同一份代码的最新版本。大多数时候git分支合并到主干，发布分支是主干某个时点的快照。以后的改 Bug 和功能增强，都是提交到主干，必要时 cherry-pick （选择部分变更集合并到其他分支）到发布分支。与主干长期并行的特性分支极为少见。
主干开发的分支策略虽然有利于开展持续交付，但是它对开发团队的能力要求较高。
主干开发的优缺点如下表所示
特性开发Git Flow
Git Flow 模型在 2011 年左右被大家当作了推荐的分支模型，至今也还有项目团队在使用。
产品分支策略基本情况分支管理
在代码分支管理的层面上，V3C团队源代码分为五个主要分支：
分支合并时间初始化配置
分支初始化配置指令：
git checkout -b hotfix origin/hotfix //创建hotfix分支
git branch --set-upstream-to origin/hotfix //关联到远端hotfix分支
git checkout -b dev origin/dev //创建dev分支
git branch --set-upstream-to origin/dev //关联到远端dev分支
git checkout -b release origin/release //创建release分支
git branch --set-upstream-to origin/release //关联到远端release分支
迭代开发
紧急bug修复预览版（Bata）
稳定版（正式版）
紧急bug修复流程
git checkout hotfix //切换到hotfix分支
git pull gitlab master //更新从远端主分支更新代码，会同时更新本地、远端的hotfix分支
//改bug...
git commit -a -m "~修复client心跳检查接口null引用 #V3C-666" //提交代码
git push //push 代码到远端hotfix分支
//bug改完了，编译测试验证，合并代码：
//1.合并代码到dev分支
git checkout dev //切换到dev分支
git pull //跟新代码
git merge --no-ff hotfix //把hotfix分支合并到当前dev分支
git commit -a -m “merge hotfix branch” //提交代码到本地dev分支仓库
git push //push 代码到服务器端dev分支
//2. 合并代码到主分支，在gitlab上操作，发送Push Request
日常特性开发
推荐日常开发中多创建本地特性分支git分支合并到主干，标准流程如下：
git checkout -b dev-rpccompress dev //创建特性分支
git commit -a -m”注释” //修改代码并提交
git checkout dev //切换到dev分支
git pull //从远端更新dev分支代码
git merge --no-ff dev-rpccompress //合并特性分支到dev
git push //推送
git branch -d dev-rpccompress //删除特性分支
Git工作流
Git常用指令代码合并
git merge --no-ff hotfix
--no-ff ：禁用快速合并，合并后会保留原分支的commit历史记录，如右图左侧图示，推荐的用法。
git merge 撤销（未push）
git checkout 【行merge操作时所在的分支】
git reset --hard 【merge前的版本号】
Git撤销&回滚操作
撤销所有本地改动代码：
git checkout . #撤销本地所有修改，未提交（暂存区），可以指定文件
$ git reset --hard HEAD #撤销本地所有修改
git commit 后撤销（reset：本地仓库撤销commit，不会影响远程仓库）
git reset --hard #回滚到某个变更集版本，针对已commit，未push
git push撤销（revert，用一个新的提交来覆盖当前版本）
git revert -m #回滚已经push的变更集，完了后push即可
git push
注意：reset、revert都会导致指定后的变更都没有了，慎重使用。
拣选指令
拣选指令–git cherry-pick其含义就是从众多的提交中选出一个提交应用在当前的工作分支中.该命令需要提供一个提交ID作为参数.操作过程相当于将该提交,导出为补丁文件,然后在当前HEAD上重放,形成无论内容还是提交说明都一致的提交.
git cherry-pick
git cherry-pick 6bbf6b4 cc63c15 #可以指定多个CommitID
git log -n20 #查看日志，获取CommitID
Git代码提供规范基本原则提交注释规则
格式：[前缀：+-*~][正文]#[相关youtrack任务编号]
+ 添加功能/模块，前缀“+”；
- 删除功能/模块，前缀“-”；
* 修改、优化功能/模块，前缀“*”；
~ 解决Bug，前缀“~”；
示例
+添加登录拦截校验功能 #V3C-1240
-删除登陆弹出框提示 #V3C-1241
*修改登陆校验逻辑 #V3C-1242
~修复登录正确提升不准确缺陷 #V3C-1243
关联的youtrack任务单/缺陷单编号，例如：“V3C-124”；
参考资料：
[1] Git Flow—Git团队协作最佳实践：
[2] Git工作流指南：
[3] 廖雪峰的 Git教程：
限时特惠：本站每日持续更新海量设计资源，一年会员只需29.9元，全站资源免费下载
站长微信：ziyuanshu688
htebazile
