同享 Java、.NET、Javascript、功率、软件工程、编程语言等技术知识。

本文 GitHub TechShare 已收录，没有广告，Just For Fun。

零、前语

  1. 本文档适用于需求继续发布的网站项目（后端、前端），稍加修正能够适用于需求一起存在不同版别的项目（框架、组件、app等）。
  2. 该作业流程根据 git flow 分支战略，该战略的长处是分支清晰，能够敷衍开发流程中的许多状况，缺陷是分支较多，开发进程中会常常需求进行兼并操作，于是在根据该战略的根底上做恰当的简化，并考虑并行迭代的状况，综合拟定了该作业流程。

本文档共包含分支战略、作业流程、分支运用标准、代码提交标准四个部分，分支战略首要是对 git flow 的介绍，作业流程部分则描绘在详细开发进程中该如何实施，分支运用标准详细描绘每种分支的用法，最后的代码提交标准是成功推动代码检查的要害因素。

1、术语阐明

  • 继续集成/CI：运用该术语一般指 feature 分支的代码频频集成到 develop 分支，并由CI自动构建到测验环境，feature 集成到 develop 一天内最少一次。
  • 继续集成环境：根据特定分支配置的自动构建、运转测验和布置测验程序的环境。
  • 预发布环境：接近出产的环境，而非测验环境。

一、分支战略

1、分支战略

首要分支战略根据 git flow，但根据复杂多变的项目研发进程会有所不同。

Git flow首要流程见下图，详细运用可参阅：www.ruanyifeng.com/blog/2012/0…

网站项目 Git 使用流程和规范

2、长时刻分支

  • master：用于存放对外发布的版别，任何时候在这个分支拿到的都是安稳的版别。
  • develop：用于日常的开发，存放最新的开发版别。

3、暂时分支

  • feature：用于开发特定功用从develop中分出来的，一个feature分支对应一次迭代开发，开发完结后兼并到develop分支中；
  • hotfix：用于修正bug，从master中分出来的，开发完结后兼并到master、deveop分支。
  • release：指发布正式版别之前（即兼并到Master分支之前），我们或许需求有一个预发布的版别进行测验。

二、作业流程

注：以下文字中粗体为特殊状况，大多数时候不需考虑，从流程中去除的话，该作业流程并不复杂。

1、项目初始

  • gitlab上创建项目
  • 创建develop分支，并将其设置为保护性分支，具有Maintainer权限的用户才能够直接push和merge，其他用户需求将代码提交到自己的分支后建议merge request（以下简称MR）恳求，由Maintainer和团队成员进行代码评定决议是否承受兼并。
  • 修正master分支为不允许任何人推送，该分支只能通过MR进行变更。

网站项目 Git 使用流程和规范

2、迭代开始阶段

  • 状况1：迭代时刻较长、分工明确
  • 开发人员各自新建归于自己的feature分支，代码继续集成到develop。
  • 状况2：迭代时刻较短、分工不明确或需求多个人开发同一功用
  • 开发人员同享一个feature分支，代码继续集成到develop。
  • 状况3：迭代A、迭代B一起发动，A为首要迭代
  • 首要迭代根据状况1、2挑选开发方式，代码继续集成到develop
  • 次要迭代从develop分出sprint-{版别}，feature根据该版别开发，代码继续集成到sprint-{版别}
  • 状况4：首要迭代A已发动，突然发动迭代B
  • 迭代B从master分出sprint-{版别}，feature根据该版别开发，代码继续集成到sprint-{版别}

留意：状况2、3、4均为特殊状况，应尽量避免，尤其是3、4两种状况需求将代码继续集成到另一个版别，那么需求配置另一套继续集成环境，一起也加大了代码评定、分支兼并的麻烦。下面描绘的开发阶段以状况1为准，若为3、4状况，则需求将develop分支替换为sprint分支。

3、迭代开发阶段

  • 开发人员完结feature的开发或阶段性开发时，建议到develop的MR。
  • Maintainer和团队成员对MR进行review，拒绝的需求提交者从头修正代码后再次提交MR，承受的将兼并到develop，并自动构建到测验环境。
  • 迭代全体测验通过后进入发布预备阶段。

4、发布预备阶段

  • 关于无预发布环境的项目，跳过预备阶段，进入发布阶段。
  • 关于有预发布环境的项目，从develop中新建release为保护性分支（若已有则兼并，该分支可在布置安稳后删去）。
  • release分支构建到预发布环境进行测验，若存在bug，在该分支上进行修正。
  • 完结release分支的测验后，进入发布阶段。

5、发布阶段

  • 提交发布申请，运维审核通过后进行代码兼并
  • 存在release时，release分支兼并到develop和master，不存在时，develop兼并到master。
  • 通过master构建并发布到出产环境。
  • 在master上打上版别tag标签，符号发布。

6、线上发布回滚状况

  • 出现发布回滚状况时，兼并到master上的代码也需进行回滚操作。

7、线上bug修正

  • 从master新建hotfix分支用于修正bug。
  • 完结后将hotfix兼并到develop进行测验。
  • 测验通过后兼并到master进行发布，并打上小版别号的tag标签。
  • 若当时存在release分支，还需将hotfix兼并到release。
  • 删去hotfix分支。

三、运用标准

1、暂时分支命名标准

暂时分支 前缀 补白
feature feature- 若gitlab中包含使命issue，能够选用feature-{issueid}-{简略描绘}命名
release release- 以版别称号或版别号结尾
hotfix hotfix- 若gitlab中包含bug issue，能够选用feature-{issueid}-{简略描绘}命名
sprint sprint- 以迭代称号或版别号结尾

CI管道可通过前缀匹配进行相关的自动化操作。

分支前缀，一般用-/衔接，很少用_，表明两个词语有相关，feature分支这里实际上是一种分组，所以一般用-/，能够在前缀之后运用。

2、feature 分支运用标准

  • 分支粒度：以一个功用为单位，尽量对应gitlab上的一个使命issue，开发下一个功用时新建feature
  • 存在时刻：尽量短，兼并到develop后挑选适宜的时刻点删去feature
  • 集成频率：每天最少一次，feature要常常兼并到develop中，便于code review，开发要常常从develop中获取最新代码；
  • 兼并恳求：当feature完结的时候即可建议MR，但当一个feature开发时刻较长时，也应当尽量提前建议MR，此时可在MR中添加WIP前缀，表明当时作业正在处理中，相关人员能够提前审核，但不兼并

网站项目 Git 使用流程和规范

3、hotfix 分支运用标准

  • 与feature辨别：线上除紧迫bug修正，当需求做功用性调整并快速上线时，也需求新建hotfix分支，而非feature。

4、sprint 分支运用标准

  • sprint的运用与develop相同，也为保护性分支。
  • 需求从sprint中分出feature分支进行开发，从feature提交MR到sprint中做代码检查。

5、release分支运用标准

  • release为保护性分支。
  • 运用 hotfix 分支进行bug修正。

四、代码提交标准

先说说为什么要拟定代码提交标准。

  1. Git 是当时最盛行的代码仓办理体系，能够说是开发者的必备技术。它非常强壮，运用妥当的话能够大幅助力个人效能的进步。假如一个团队的成员都能熟练运用 Git 的话，能够大大进步团队代码的模块化、可读性、可维护性，然后进步团队的研发效能。
  2. 成功推动代码检查的两个要害操作：一是留意检查提交的原子性，二是检查中重视提交阐明（Commit Message）。

1、代码提交原子性标准

代码提交的原子性，是指一个提交包含一个不可分割的特性、修正或者优化，一起这个提交要尽或许小。假如用一个提交完结一个功用，这个提交仍是会比较大的话，我们需求把这个功用再拆分为子功用。

原子性提交的长处：

  1. 能够让代码结构更清晰、更容易了解；
  2. 出了问题之后便利定位，并能够针对性地对问题提交进行“回滚”；
  3. 在功用开关的协助下，能够让开发者尽快把代码推送到 develop/master 上进行兼并。这正是继续集成的根底。

标准要求：

  1. 一个提交包含一个不可分割的特性、修正或者优化，一起这个提交要尽或许小。

代码检查标准

  1. 不符合原子性提交的代码能够直接打回。
  2. 逐步要求提交的原子性，不要求一次性到位，但有必要逐步改进。

2、代码提交阐明标准

好的提交阐明能够进步代码可读性，一起也是进步代码检查功率的利器。通过拟定严厉的提交阐明格局来标准其质量，能够便利检查者查了解被检查代码的意图、完成思路，并通过测验状况，加快对代码的了解，进步对代码质量的决心，然后大大进步检查者的功率。一起，严厉的提交阐明格局及好的阐明质量也能够催促开发者进步代码质量。

好的格局应该包含以下几个方面：

  • 标题，简明扼要地描绘这个提交。这部分最好在 70 个字符之内，以保证在单行显现的时候能够显现完整。比方，在命令行常用的 git log –oneline 输出成果要能显现完全。
  • 详细描绘，包含提交的意图、挑选这个方法的原因，以及完成细节的总结性描绘。这三个方面的内容最能协助检查者阅读代码。
  • 测验状况，描绘的是你对这个提交做了什么样的测验验证，详细包含正常状况的输出、错误状况的输出，以及功用、安全等方面的专项测验成果。这部分内容，能够添加检查者对提交代码的了解程度以及决心。
  • 与其他工具和体系相关的信息，比方相关使命 ID、相关的冲刺（sprint，也可翻译为“迭代”）链接。这些信息对工具的网状互联供给根底信息，非常重要。

标准要求：

  1. 提交阐明有必要包含标题、测验状况两个部分。
  2. 提交阐明需求符合格局要求，根据提交的代码量，有必要时添加详细描绘、相关信息两部分。
  3. 基本格局要求（其中标题、测验两个部分有必要包含，标题有必要运用type(scope) 方式）：
标题
描绘:
测验:
相关信息:

提交阐明模板：

$type($scope):
summary: 
test: 
task id: 
BREAKING CHANGE: 
Closes：封闭issue，如#123

type 可运用以下选项：

  • feat：新功用
  • fix：修补 bug
  • docs：仅文档的改动
  • style：代码格局的改动，不影响代码运转的变化。
  • refactor：重构，即不是新增功用，也不是修正bug的代码变化
  • perf：功用优化
  • test： 添加测验
  • build：构建进程
  • chore: 不修正源代码的杂项变化

scope 用于阐明 commit 影响的规模，比方数据层、操控层、视图层等等，视项目不同而不同。

在末尾阐明其他重要信息，比方不兼容的改动、修正的 bug id 等。