Git工作流实践

发表于 更新于 分类于
本文字数： 2.2k 阅读时长 ≈ 4 分钟

在好多个工程上都使用了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，执行发布前的准备，包括小错误修复、版本元数据更新，最后合并到master和develop分支
  • hotfix：热修复分支。从master分支fork，修复实时生产环节中出现的错误，完成后合并回master和develop分支

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

github flow

翻译地址：[译]GitHub Flow

github-flow是git-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-guide和zjZSTU/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. 仅包含master和dev分支，其中dev分支存放工程源码，master分支存放编译后的HTML文件
  2. 每次上传到dev分支后触发CI工具进行编译，并发送给master分支
  3. Web服务器利用master分支进行网站发布

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

参考Git Flow和Github Flow，实现如下的分支策略：

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

代码库工程

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