【编程向导】代码管理-Git四期期讲解-Toy模板网

这篇具有很好参考价值的文章主要介绍了【编程向导】代码管理-Git四期期讲解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

nav: title: 代码管理 order: 5 title: 工作流 order: 51

工作流

Git 最强大的就是其分支功能，但是如何分支才能更有效的提高开发效率，减少因为代码合并带来的问题，需要一个分支模型来规范，其实在 Git Flow 出现之前，已经有分支模型理论流程，当时是根据此理论，手动的按照规范操作分支，Git Flow 出现之后，将一部分操作流程简化为命令，并没有增加新的功能，只是简化了操作。

import React from 'react';
import img from '../../assets/git/git-flow.png';

export default () => <img alt="Git Flow" src={img} width="640" />;

统一团队的 Git 工作流，包括分支使用、Tag 规范、Issue 等
统一团队的 Git Commit 日志标准，便于后续代码 Review，版本发布以及日志自动化生成

分支管理

Git Flow 管理方式把项目分为 5 条线，通常会是下面的管理方式。

Master：作为稳定主分支，用于部署生产环境的分支，长期有效。不可以在此分支进行任何提交，只能接受从 Hotfix 分支或者 Release 分支发起的 Merge Request，该分支上的每一个提交都对应一个 Tag 提交标签。
Develop：开发主分支，长期有效。不可以在此分支上做任何提交，只接受从 Feature 分支发起的 Merge Request。所有的 Alpha Release 都应该在这个分支发布。
Feature：功能分支，生命周期为产品迭代周期，每个分支对应一期的需求。开发新功能时，以 develop 为基础创建 feature 分支。分支命令规则 feature/user_module、feature/cart_module。可以 merge Release 分支的代码，生命周期结束后，需要 merge 回 Develop 分支。方式需要采用 Merge Request。
Release：发布分支，声明周期从新需求的预发布到正式发布，每一个分支对应一个新版本的版本号。只可以从 Develop 分支 Kick Off。声明周期结束后，需要 Merge 回 Master 及 Develop 分支，方式同样需要采用 Merge Request。所有的 Beta Release 均需要在该分支发布。
Hotfix：热修复分支，生命周期对应一个或者多个需要紧急修复并上线的 Bug，每一个分支对应一个小版本号。只可以从 Master 分支进行 Kick Off。声明周期结束后，需要 merge 回 Master 分支和 Develop 分支，方式当然也是采用 Merge Request。

在研发流程中分支通常对应不同的部署环境：

tag -> 生产环境（Production）
master -> 预发布/灰度环境（Pre-Production/Staging）
develop -> 测试环境（Test）

实际上，如果你熟悉 Git 的话，你会很快发现上面的管理方式会存在历史提交非常混乱的缺点，但觉得不失为一个 Git 分支管理的经典。实际上，我们可以用 rebase 去替换 merge 让 commit 看起来更加清晰。对 rebase 和 merge 的优劣对比这里暂不做讲解，感兴趣的可以直接 Google 搜索。

提交规范

业界使用比较广泛的代码提交规范是：Angular Git Commit Guidelines

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

占位标签解析：

type：代表某次提交的类型，比如是修复了 BUG 还是新增了 Feature
scope：说明 Commit 影响的范围，根据项目而定。例如在业务项目中可以依据菜单活功能模块划分；如果是组件库开发，则可以依据组件划分。
subject：Commit 的简短描述
body：提交代码的详细描述
footer：如果代码的提交是不兼容变更或关闭缺陷，则 Footer 必需，否则可以省略

提交类型

类型	说明
feat	特性：新功能
fix	修复：修复错误
docs	文档：文档修改（比如 README.md、CHANGELOG、CONTRIBUTE 等等）
style	格式：格式修改（不影响代码运行的变化，如空白、格式化、缺少分号等）
refactor	重构：代码重构（既不新增功能，也不是修改错误的代码变动）
perf	优化：改进性能的代码更改
test	测试：测试用例，包括单元测试、集成测试（添加缺失测试或更正现有测试）
chore	工具：构建过程或辅助工具的变动（或者增加依赖库、工具等）
revert	回滚：回滚到上一个版本

示例：

特性: 添加头像功能
特性: 添加收藏功能
修复: 在 Android 机器上传崩溃问题解决
文档: 修改 README，增加了使用说明
优化: 首页图片加载缓慢优化
重构: 对头像功能进行封装重构

格式要求

Git Commit 代码提交的标题、内容的格式要求。

# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到 issue 地址或者其它文档

辅助工具

用于约束 commit 的插件工具：

commitizen：一个格式化 commit message 的工具
commitlint：检查 commit message 是否符合常规的提交格式
conventional-changelog-cli：每次 commit 后产生 CHANGELOG 日志文件
@commitlint/config-conventional：一些常规的 commitlint 规则，如果不满足，将产生一个非零的退出代码，退出当前执行程序

辅助工具：

husky：Git Hooks

标签版本管理

项目标签版本管理的规范有多种多样，这里我们讲述的是版本语义化版本 2.0.0 的规范。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改
次版本号：当你做了向下兼容的功能性新增
修订号：当你做了向下兼容的问题修正

先行版本号及版本编译元数据可以加到 主版本号.次版本号.修订号 的后面，作为延伸。

命名规范：

新功能开发使用第二位版本号，BUG 修复使用第三位版本号
首版本号是全新的功能类，功能模块上线才做的调整

钩子

Git 钩子（hooks）是在 Git 仓库中特定事件（certain points）触发后被调用的脚本。通过钩子可以自定义 Git 内部的相关（如 git push）行为，在开发周期中的关键点触发自定义的行为。Git 含有两种类型的钩子：客户端的和服务器端的。客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。

Git 钩子最常见的使用场景包括根据仓库状态改变项目环境、接入持续集成工作流等。由于脚本是可以完全定制，所以你可以用 Git 钩子来自动化或者优化你开发工作流中任意部分。

作用域

Git 钩子是对本地仓库相关操作影响，对于任何 Git 仓库来说钩子都是本地的，初始的钩子都是从 Git 默认模板目录中自动安装。

在开发团队中为了保持团队所使用钩子一致，维护起来算是比较复杂的，因为 .git/hooks 目录不随你的项目一起拷贝，也不受版本控制影响。

客户端钩子

客户端钩子分为很多种。下面把它们分为：提交工作流钩子、电子邮件工作流钩子和其它钩子。

需要注意的是，克隆某个版本库时，它的客户端钩子并不随同复制。如果需要靠这些脚本来强制维持某种策略，建议你在服务器端实现这一功能。

提交工作流钩子

前四个钩子涉及提交的过程。

pre-commit

pre-commit 钩子在执行 git commit 命令时，键入提交信息前运行。它用于检查即将提交 commit 的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit --no-verify 来绕过这个环节。你可以利用该钩子，来检查代码风格是否一致（运行类似 lint 的程序）、尾随空白字符是否存在（自带的钩子就是这么做的），或新方法的文档是否适当。

prepare-commit-msg

prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。它允许你编辑提交者所看到的默认信息。该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。你可以结合提交模板来使用它，动态地插入信息。

commit-msg

commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。常用于校验提交说明是否标准。

post-commit

post-commit 钩子在整个提交过程完成后运行。它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。该钩子一般用于邮件通知、提醒之类的事情。

电子邮件工作流钩子

你可以给电子邮件工作流设置三个客户端钩子。它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。

pplypatch-msg

第一个运行的钩子是 applypatch-msg 。它接收单个参数：包含请求合并信息的临时文件的名字。如果脚本返回非零值，Git 将放弃该补丁。你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。

下一个在 git am 运行期间被调用的是 pre-applypatch 。有些难以理解的是，它正好运行于应用补丁之后，产生提交之前，所以你可以用它在提交前检查快照。你可以用这个脚本运行测试或检查工作区。如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。

post-applypatch

post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。你可以用它把结果通知给一个小组或所拉取的补丁的作者。但你没办法用它停止打补丁的过程。

其他客户端钩子

服务端钩子

除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。这些钩子脚本在推送到服务器之前和之后运行。推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。

pre-receive

处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。

update

update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。

post-receive

post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。它接受与 pre-receive 相同的标准输入数据。它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器，或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态，所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。

参考资料：文章来源地址https://www.toymoban.com/news/detail-847028.html