Git工作流实践

在好多个工程上都使用了git,随着时间的拉长会发现工程的提交历史和分支管理很混乱,所以希望能够有一套规范的git使用流程来更好的实现版本管理

参考Git三大特色之WorkFlow(工作流),学习了目前最流行的三种git工作流

git flow

翻译地址:[译]A successful Git branching model

git-flow是最早发布的git工作流,其思路简洁清晰,通过5种分支类型即可管理整个工程

  • master:主分支。保存后续生产环节的代码
  • develop:开发分支。当实现功能足以反映下一版本的状态时,发布给release分支
  • feature:特征分支。从develop分支fork,开发某个新特性,完成后合并回develop
  • release:发布分支(或称为版本分支)。从develop分支fork,执行发布前的准备,包括小错误修复、版本元数据更新,最后合并到masterdevelop分支
  • hotfix:热修复分支。从master分支fork,修复实时生产环节中出现的错误,完成后合并回masterdevelop分支

其中前两种分支属于主分支,长期存在于中间仓库中,后3种分支属于支持分支,完成所需要的目的后即可销毁

github flow

翻译地址:[译]GitHub Flow

github-flowgit-flow的一个补充,提供了更加简单的工作流程。github-flow适用于持续部署的工程,直接将最新特征部署到master分支上,不再操作develop分支;同时通过CI&CD的使用,不再需要额外操作release分支和hotfix分支。github还结合了推送请求(pull request)功能,在合并feature分支之前通过PR请求其他成员对代码进行检查

  • master分支中的任何东西都是可部署的
  • 要开发新的东西,从master分支中创建一个描述性命名的分支(比如:new-oauth2-scopes)
  • 在本地提交到该分支,并定期将您的工作推送到服务器上的同一个命名分支
  • 当您需要反馈或帮助,或者您认为分支已经准备好合并时,可以提交一个推送请求(PR
  • 在其他人审阅并签署了该功能后,可以将其合并到master
  • 一旦它被合并并推送到主服务器,就可以并且应该立即部署

gitlab flow

翻译地址:[译]Introduction to GitLab Flow

gitlab-flow出现的时间最晚,其内容更像是对前两者的补充,通过集成git工作流和问题跟踪系统,提供更加有序的关于环境、部署、发布和问题集成的管理

当前实践

以上3种工作流各有所长,提供了不同工作环境下的分支策略和发布管理实践。结合自身实际需求,基于上述方法针对不同的项目进行调整

当前操作的工程大体分为三类:

  1. 文档工程
  2. 网站工程
  3. 代码库工程

文档工程

文档工程指的是仓库存储的仅是文档以及文档生成框架,比如zjZSTU/wall-guidezjZSTU/linux-guide,通常这些文档工程会结合readthedocs进行CI&CD的实现;有些文档工程会额外包含一些代码文件,比如zjZSTU/Containerization-Automation,里面包含了多个生成docker镜像的dockerfiles文件以及相关的配置文件

主要参考GitHub Flow,实现如下的分支策略:

  1. 文档可直接发布到master分支
  2. 要更新文档生成框架,需要创建特征分支,完成更新后再合并到master分支(注意:合并前需要标记master分支,注明之前使用的版本
  3. 每次添加新的代码功能,需要创建特征分支,完成更新后再合并到master分支
  4. 如果需要修复已有的代码错误,直接在master分支上操作

网站工程

当前网站工程指的是基于Hexo的博客网站使用,博客网站主要包含3方面内容:

  1. 网站框架
  2. 主题
  3. 文档

通常主题会在另一个仓库中管理,当前仓库中仅包含网站框架以及文档,同时还会包含CI配置文件

网上推荐的一种工作流比较简单:

  1. 仅包含masterdev分支,其中dev分支存放工程源码,master分支存放编译后的HTML文件
  2. 每次上传到dev分支后触发CI工具进行编译,并发送给master分支
  3. Web服务器利用master分支进行网站发布

在实际操作中发现并不是每次上传到dev分支的修改都有必要通过CI工具进行编译,比如README.md;同时,在测试、更新CI工具和网站生成工具时,过多的调试不利于之后log的查询

参考Git FlowGithub Flow,实现如下的分支策略:

  1. master分支存放编译好的网站文件
  2. dev分支存放仓库源码
  3. 文档文件直接上传到dev分支(区分是否需要编译,通过CI文件进行判断
  4. 要添加新的CI功能,需要创建特征分支,完成调试后再合并到dev分支
  5. 要更新网站生成框架,需要创建特征分支,完成调试后再合并到dev分支(注意:合并前需要标记dev分支,注明之前使用的版本
  6. 修复CI配置文件或者网站配置文件错误,直接上传到dev分支

代码库工程

代码库工程是最常见的仓库类型,比如博客网站配套的主题仓库,zjZSTU/PyNetzjZSTU/GraphLib,里面不仅包含源代码,还有可能包含文档、图片、CI文件等等,对于个人操作而言,比较适用于GitHub Flow,通过快速的更新和迭代来完成开发

坚持原创技术分享,您的支持将鼓励我继续创作!