持续交付之基于Git Flow代码分支策略实践

分手后的思念是犯贱 2021-12-21 10:43 180阅读 0赞

转自：  [https://blog.csdn.net/zuozewei/article/details/93862974][https_blog.csdn.net_zuozewei_article_details_93862974]

文章目录  
前言  
主干开发（TBD）  
特性开发  
Git Flow  
产品分支策略  
基本情况  
分支管理  
分支合并时间  
初始化配置  
迭代开发  
紧急bug修复  
预览版（Bata）  
稳定版（正式版）  
紧急bug修复流程  
日常特性开发  
Git工作流  
Git常用指令  
代码合并  
Git撤销&回滚操作  
拣选指令  
Git代码提供规范  
基本原则  
提交注释规则  
前言  
高效的持续交付体系，必定需要一个合适的代码分支策略。采用不同的代码分支策略，意味着实施不同的代码集成与发布流程，这会影响整个研发团队每日的协作方式，因此研发团队通常需要很认真地选择自己的策略。

主干开发（TBD）  
主干开发是一个源代码控制的分支模型，开发者在一个称为 “trunk” 的分支（Git 称 master）中对代码进行协作，除了发布分支外没有其他开发分支。

Google 和 Facebook 都是采用“主干开发”的方法,代码一般直接提交到主干的头部，这样可以保证所有用户看到的都是同一份代码的最新版本。大多数时候，发布分支是主干某个时点的快照。以后的改 Bug 和功能增强，都是提交到主干，必要时 cherry-pick （选择部分变更集合并到其他分支）到发布分支。与主干长期并行的特性分支极为少见。

主干开发的分支策略虽然有利于开展持续交付，但是它对开发团队的能力要求较高。

主干开发的优缺点如下表所示

特性开发  
Git Flow  
Git Flow 模型在 2011 年左右被大家当作了推荐的分支模型，至今也还有项目团队在使用。

主分支：master，稳定版本代码分支，对外可以随时编译发布的分支，不允许直接Push代码，只能请求合并（pull request），且只接受hotfix、release分支的代码合并。gitlab上做权限限制（开发组长）。  
热修复分支：hotfix，针对现场紧急问题、bug修复的代码分支，修复完后合并到主分支、开发分支。  
发版分支：release，版本发布分支，用于迭代版本发布。迭代完成后，合并dev代码到release，在release分支上编译发布版本，以及修改bug（定时同步bug修改到dev分支）。测试完成后此版本可以作为发版使用，然后把稳定的代码push到master分支，并打上版本标签。  
开发分支：dev，开发版本分支，针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到release分支。  
特性开发分支：dev-\*\*\*，开发人员可以针对模块自己创建本地分支，开发完成后合并到dev开发分支，然后删除本地分支，涉及多人协同开发的可以push到服务端。  
产品分支策略  
基本情况  
尚不具备主干开发能力（开发团队系统设计和开发能力非常强）  
有预定的发布周期  
需要严格执行发布周期  
分支管理  
在代码分支管理的层面上，V3C团队源代码分为五个主要分支：

Master：主分支，稳定版本  
Hotfixes：补丁分支，稳定/预览版本或现场问题的应急处理  
Release：预览分支，Bata版/测试与bug修复  
Develop：开发分支，常规功能的新增与调整  
Feature：特性分支，同时可以有多个特性分支，代码合并后结束；

分支合并时间  
主分支：每个季度一个正式版本，于每个季度末合并发版；由预览分支、补丁分支合并；不允许直接Push代码，只能合并；  
补丁（热修复）分支：随现场使用情况而定，可以打临时版本或补丁；由主分支替换而来，修复完后合并到主分支、开发分支；  
预览分支：版本发布分支，用于迭代版本发布。每日测试打版验证，由开发分支合并而来；测试完成后此版本可以作为发版使用，然后把稳定的代码push到master分支，并打上版本标签。  
开发分支：不对外发布，可以由其他分支合并而来；针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到release分支；  
特性分支：不直接打版，可以由开发分支合并而来；新功能稳定后合并到开发分支  
初始化配置

分支初始化配置指令：

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引用 \#V3C666"         //提交代码  
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 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工作流

工作区：就是你在电脑里能看到的代码库目录。  
暂存区：英文叫stage, 或index。一般存放在 “.git目录下” 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。这个分区我们平时使用较少，不做多介绍。  
本地仓库（版本库）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。我们在工作区修改的代码通过Commit指令提交到版本库。  
服务端仓库（远端版本库）：服务端的版本库，本地版本库通过push指令把代码提交到远端版本库。

Git的分支创建、切换、删除都非常快，分支是Git的必杀技特性。要充分利用Git的分支特性，特别是个人开发时多使用Feature分支。  
上图是一个普遍采用的分支管理方案  
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-id>  \#回滚到某个变更集版本，针对已commit，未push  
git push撤销（revert，用一个新的提交来覆盖当前版本）  
git revert <commit-id> -m \#回滚已经push的变更集，完了后push即可  
git push  
  
注意：reset、revert都会导致指定后的变更都没有了，慎重使用。

拣选指令  
拣选指令–git cherry-pick 其含义就是从众多的提交中选出一个提交应用在当前的工作分支中.该命令需要提供一个提交ID作为参数.操作过程相当于将该提交,导出为补丁文件,然后在当前HEAD上重放,形成无论内容还是提交说明都一致的提交.

git cherry-pick <commit id>  
git cherry-pick 6bbf6b4 cc63c15 \#可以指定多个CommitID  
git log -n20  \#查看日志，获取CommitID  
  
Git代码提供规范  
基本原则  
Git 代码完整提交正确姿势，建议先 Commit，再 Pull，最后 Push。  
代码提交前，保证本地编译通过。  
代码提交时，保证代码、文件完整提交，不要把本地测试代码、配置提交上去了。  
代码每次独立的功能、模块修改，都 Commit 到本地(不急每次都 Push)  
较大的模块开发或修改建议创建本地特性分支，完成后合并到 dev，特性分支不可 push  
提交注释规则  
格式：\[前缀：+ - \* ~\]\[正文\] \#\[相关youtrack任务编号\]

\+ 添加功能/模块，前缀“+”；  
\- 删除功能/模块，前缀“-”；  
\* 修改、优化功能/模块，前缀“\*”；  
~ 解决Bug，前缀“~”；  
  
示例

\+添加登录拦截校验功能 \#V3C-1240  
\-删除登陆弹出框提示 \#V3C-1241  
\*修改登陆校验逻辑 \#V3C-1242  
~修复登录正确提示不准确缺陷 \#V3C-1243  
  
关联的youtrack任务单/缺陷单编号，例如：“V3C-124”；

参考资料：  
\[1\] Git Flow—Git团队协作最佳实践： https://yq.aliyun.com/articles/68655  
\[2\] Git工作流指南： https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md  
\[3\] 廖雪峰的 Git教程：https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000  
\---------------------   
作者：zuozewei   
来源：CSDN   
原文：https://blog.csdn.net/zuozewei/article/details/93862974   
版权声明：本文为博主原创文章，转载请附上博文链接！

[https_blog.csdn.net_zuozewei_article_details_93862974]: https://blog.csdn.net/zuozewei/article/details/93862974