git使用及提交规范

合集下载

git、gerrit的使用方法和规范方案

git、gerrit的使用方法和规范方案

git、gerrit的使用方法和规范1、新员工git安装环境准备首先从服务器端ftp://192.168.31.10/Software/Tool/Git/(用户名/密码 paypalm/paypalms)获取软件Git-1.9.4-preview20140929 1、默认安装Git-1.9.4-preview20140929安装完成后打开git bash编辑器生成密钥对:ssh-keygen -t rsa 按三次回车键,默认生成路径如下图将生成的公钥内容在gerrit中进行添加(参考下文gerrit注册使用)每个人不同环境可以添加多个对应的公钥cat ~/.ssh/id_rsa.pub2、gerrit注册使用1、申请账号通过邮件向PPCM@发邮件申请,打开gerrit网站(http://192.168.31.10:8088),登录后在右上角进行setting设置2、公钥添加点击SSH Public Keys》Add Key选项进行公钥添加3、邮箱注册点击Register New Email 进行邮箱注册,注册后有邮件发送至你的邮箱点开链接重新登录3、gerrit主要功能介绍1、常规功能1、登录gerrit》ALL》open状态,此显示为已推送但还没有入库的所有patch,CR状态栏中绿色对勾代表已评审状态,可以根据计划入库2、gerrit》ALL》Merged状态表示所有已经进入项目库的patch3、提交patch后,开发人员可能觉得不太满意会选择放弃,gerrit》ALL》Abandoned 即为已放弃的patch,只有还没有入库的patch才能选择放弃,点击进入patch,橘黄色Abandon即为放弃选项,放弃后的patch依然可以进行还原,如以下操作橘黄色Restore为还原选项4、gerrit》Projects》List状态表示服务器端所有项目列表5、gerrit》People》List Groups状态表示所有组列表2、评审功能1、点击进入待评审的patch,点击add添加Reviews人员进行评审评审人员点击Reply进行评审打分,每一个需要入库的patch必须具备两分+2方可,1分表示自己同意,2分表示完全同意,负分表示不支持此代码入库2、gerrit》My》Changes状态为需要自己给别人进行评审的状态4、git命令使用1、账户名和邮箱设置查看1)、每一个工作环境首先配置在gerrit中注册的账户名和邮箱,请确保一致# git config --global “your-account”# git config --global user.email “your-email”# git config -l2、项目库clone根据gerrit项目列表,查看项目下载地址,选择clone with commit-msg hook&&ssh 选项,请确保正确方式进行项目库下载git clone ssh://your-accout@192.168.31.10:29418/Test3、提交注意事项每一个新clone的库第一次提交都需要执行以下步骤(下载服务端钩子到本地库,以便提交评审形成chang-id)scp -p -P 29418 your-account-name @192.168.31.10:hooks/commit-msg .git/hooks/git config remote.origin.push refs/heads/*:refs/for/*当执行完以上步骤,第一次git push依然会产生missing Change-Id错误,用git commit --amend命令把错误信息中的changed id进行添加,如下图本地工作库中,以最后一次成功push为节点,如果超过两条commit信息也会产生此错误合并多条commit为一条记录,可以用git reset 后跟要回退到最新push成功的版本号,整合多条记录为一条如产生uppack error和changed closed,建议保存工作库中修改文件,并进行强制回退、重新同步最新代码,以修复工作库index。

Git工作流程规范与多人协作实践

Git工作流程规范与多人协作实践

Git工作流程规范与多人协作实践一、引言Git是一种分布式版本控制系统,具有快速、安全、强大等优点。

而在多人协作环境下,如何规范Git的工作流程,是保证协作效率和代码质量的重要因素。

本篇文章将从规范Git工作流程和多人协作实践两个方面进行讲解。

二、Git工作流程规范1. 分支管理在Git中,常见的分支管理方式有以下几种:(1)集中式工作流在该工作流中,有一个主分支(master)作为代码的唯一来源,其它分支都基于此分支创建。

优点:简单、容易控制。

缺点:固定的流程容易出现合并冲突、开发效率较低。

(2)功能分支工作流在该工作流中,每个功能或Bug变更都会创建一个新分支,一旦开发完成,该分支会被合并到主分支中。

优点:团队成员可以在独立的分支中开发功能、提交、测试并发布。

缺点:需要更多的分支管理工作,需要更多的协作与沟通。

(3)GitFlow工作流该工作流将功能分支工作流与主分支结合起来,在开发和发布时更灵活。

优点:适用于大多数项目的复杂性和需求,较为适用。

缺点:需要更多的分支管理工作。

2. 提交信息规范为规范提交信息,有以下几点建议:(1)提交信息要简洁明了(2)首字母大写,末尾无标点符号(3)描述变更的类型(4)用一句话简单描述变更的原因3. 版本号规范版本号是软件的标识,Git使用的版本号有以下三个:(1)主版本号(major):当你进行大量的 API 修改时,主版本号加 1。

(2)次版本号(minor):当你添加新功能时,但是不破坏任何现有功能的兼容性时,次版本号加 1。

(3)修订号(patch):当你正在进行 Bug 修复时,修订号加1。

4. 代码审核规范代码审核可以有效提高代码质量,规范代码交付和合并流程。

在进行代码审核时,可以考虑以下几点:(1)指定负责人或团队(2)把代码库与编译、测试和构建脚本整合在一起(3)评估潜在的风险和安全问题(4)对代码进行审查、测试和复查三、多人协作实践在多人协作中,协作的质量和流程大大影响着项目的成功。

git、gerrit的使用方法和规范方案

git、gerrit的使用方法和规范方案

git、gerrit的使⽤⽅法和规范⽅案git、gerrit的使⽤⽅法和规范1、新员⼯git安装环境准备⾸先从服务器端ftp://192.168.31.10/Software/Tool/Git/(⽤户名/密码 paypalm/paypalms)获取软件Git-1.9.4-preview20140929 1、默认安装Git-1.9.4-preview20140929安装完成后打开git bash编辑器⽣成密钥对:ssh-keygen -t rsa 按三次回车键,默认⽣成路径如下图将⽣成的公钥内容在gerrit中进⾏添加(参考下⽂gerrit注册使⽤)每个⼈不同环境可以添加多个对应的公钥cat~/.ssh/id_rsa.pub2、gerrit注册使⽤1、申请账号通过邮件向PPCM@/doc/10fd88fb76232f60ddccda38376baf1ffd4fe36f.html 发邮件申请,打开gerrit⽹站(http://192.168.31.10:8088),登录后在右上⾓进⾏setting设置2、公钥添加点击SSH Public Keys》Add Key选项进⾏公钥添加3、邮箱注册点击Register New Email 进⾏邮箱注册,注册后有邮件发送⾄你的邮箱点开链接重新登录3、gerrit主要功能介绍1、常规功能1、登录gerrit》ALL》open状态,此显⽰为已推送但还没有⼊库的所有patch,CR状态栏中绿⾊对勾代表已评审状态,可以根据计划⼊库2、gerrit》ALL》Merged状态表⽰所有已经进⼊项⽬库的patch3、提交patch后,开发⼈员可能觉得不太满意会选择放弃,gerrit》ALL》Abandoned 即为已放弃的patch,只有还没有⼊库的patch才能选择放弃,点击进⼊patch,橘黄⾊Abandon即为放弃选项,放弃后的patch依然可以进⾏还原,如以下操作橘黄⾊Restore为还原选项4、gerrit》Projects》List状态表⽰服务器端所有项⽬列表5、gerrit》People》List Groups状态表⽰所有组列表2、评审功能1、点击进⼊待评审的patch,点击add添加Reviews⼈员进⾏评审评审⼈员点击Reply进⾏评审打分,每⼀个需要⼊库的patch必须具备两分+2⽅可,1分表⽰⾃⼰同意,2分表⽰完全同意,负分表⽰不⽀持此代码⼊库2、gerrit》My》Changes状态为需要⾃⼰给别⼈进⾏评审的状态4、git命令使⽤1、账户名和邮箱设置查看1)、每⼀个⼯作环境⾸先配置在gerrit中注册的账户名和邮箱,请确保⼀致# git config --global/doc/10fd88fb76232f60ddccda38376baf1ffd4fe36f.html “your-account”# git config --global user.email “your-email”# git config -l2、项⽬库clone根据gerrit项⽬列表,查看项⽬下载地址,选择clone with commit-msg hook&&ssh 选项,请确保正确⽅式进⾏项⽬库下载git clone ssh://your-accout@192.168.31.10:29418/Test3、提交注意事项每⼀个新clone的库第⼀次提交都需要执⾏以下步骤(下载服务端钩⼦到本地库,以便提交评审形成chang-id)scp -p -P 29418 your-account-name @192.168.31.10:hooks/commit-msg .git/hooks/git config remote.origin.push refs/heads/*:refs/for/*当执⾏完以上步骤,第⼀次git push依然会产⽣missing Change-Id错误,⽤git commit --amend命令把错误信息中的changed id进⾏添加,如下图本地⼯作库中,以最后⼀次成功push为节点,如果超过两条commit信息也会产⽣此错误合并多条commit为⼀条记录,可以⽤git reset 后跟要回退到最新push成功的版本号,整合多条记录为⼀条如产⽣uppack error和changed closed,建议保存⼯作库中修改⽂件,并进⾏强制回退、重新同步最新代码,以修复⼯作库index。

Git源代码管理规范

Git源代码管理规范

使用git 进行源代码管理,普通将某个项目的所有分支分为以下几条主线:Master顾名思义,既然名字叫 Master ,那末该分支就是主分支的意思。

master 分支永远是production-ready 的状态,即稳定可产品化发布的状态。

Develop这个分支就是我们寻常开辟的一个主要分支了,不管是要做新的 feature 还是需要做bug fix ,都是从这个分支分出来做。

在这个分支下主要负责记录开辟状态下相对稳定的版本,即完成为了某个 feature 或者修复了某个 bug 后的开辟稳定版本。

Feature branches这是由许多分别负责不同 feature 开辟的分支组成的一个分支系列。

new feature 主要就在这个分支系列下进行开辟。

当功能点开辟测试完毕之后,就会合并到 develop 分支去。

release branches这个分支系列从 develop 分支出来,也就是预发分支。

在预发状态下,我们往往会进行预发环境下的测试,如果浮现缺陷,那末就在该 release 分支下进行修复,修复完毕测试通过后,即分别并入 master 分支后 develop 分支,随后 master 分支做正常发布。

Hotfix branches这个分支系列也就是我们常说的紧急线上修复,当线上浮现 bug 且特殊紧急的时候,就可以从 master 拉出分支到这里进行修复,修复完成后分别并入 master 和 develop 分支。

下面这张图将完整展示这一个流程Git 的工作方式:也就是说,每次提交版本变动的时候,git 会保存一个快照(snapshot)。

如果文件没有被更改,git 也不会再次保存,而是提供一个到原来文件的链接。

这样一来,git 更像是一个小型的文件系统。

此外,( repository )是 Git 保存元数据和对象数据库的地方。

这也是 Git 最重要的部份。

(working directory )是项目某个版本的内容。

git提交正则校验规则

git提交正则校验规则

git提交正则校验规则Git是一款广泛使用的版本控制系统,能够帮助团队协作开发和管理代码。

在使用Git提交代码时,我们经常需要对提交的内容进行校验,以保证代码的规范和质量。

正则表达式是一种强大的工具,可以用来校验字符串是否符合特定的模式。

本文将介绍如何使用Git 提交正则校验规则。

在使用Git提交代码时,我们可以通过pre-commit钩子来进行校验。

pre-commit钩子是在执行提交操作之前被触发的,我们可以在这个钩子中编写正则校验规则,来检查我们提交的代码是否符合要求。

下面是一个示例的pre-commit钩子脚本:```bash#!/bin/sh# 获取即将提交的文件列表files=$(git diff --cached --name-only --diff-filter=ACM)# 定义正则校验规则pattern="^(\w+\.txt)$"# 遍历每个文件,进行校验for file in $files; doif ! echo "$file" | grep -qE "$pattern"; thenecho "Error: $file does not match the regex pattern $pattern"exit 1fidoneexit 0```上面的脚本中,我们首先通过`git diff --cached --name-only --diff-filter=ACM`命令获取即将提交的文件列表。

然后,我们定义了一个正则表达式的模式,用来匹配文件名是否符合要求。

接着,我们遍历每个文件,使用`grep`命令来进行匹配校验。

如果文件名不符合正则表达式的模式,我们就输出错误信息并退出提交操作。

使用正则校验规则可以确保我们提交的文件名符合一定的规范,比如文件名必须以`.txt`结尾。

这样可以避免一些常见的错误,比如提交了错误的文件类型或者文件名格式不正确。

GIT版本库操作手册及管理规范

GIT版本库操作手册及管理规范

GIT版本库操作手册及管理规范FESCO Adecco公司内部自建系统GIT代码版本库操作手册及管理规范版本<1.0>文档版本历史【目录】1概述 (4)1.1编写目的 (4)1.2适用范围 (4)1.3名词解释 (4)2GIT操作使用说明 (5)2.1GIT工具的安装及权限开放申请 (5)2.2GIT工具的使用 (6)2.2.1从GIT导入项目 (6)2.2.2创建分支 (11)2.2.3代码提交 (12)2.2.4版本切换 (14)2.2.5代码同步 (14)2.2.6其他 (15)3GIT版本库管理规范 (15)4GIT版本结构图 (17)5GIT代码管理执行流程图 (18)1概述1.1 编写目的本文主要用于对公司内部自主研发的系统进行代码的版本管理,同时指导公司内部开发人员使用GIT工具进行统一的管理规范。

本文所形成的规范将作为IT部门开发的标准流程进行管控,不定时的进行线上环境的抽查,各项目架构师也应当以此文进行严格的版本管理及执行监督。

1.2 适用范围所有公司内部自主研发的项目。

1.3 名词解释UAT环境:用于用户做验收时进行测试的环境,其中数据均为线上生产数据的备份,在未约定与用户进行验收测试的情况下,不对业务部门开放。

测试环境:包含所有开发代码的环境,用于提供用户进行培训、演示等用途的临时环境,数据为加密及改版过的测试数据。

PRO分支:用于执行ANT脚本进行自动发布的GIT环境,此处的代码必须与生产环境完全保持一致。

UAT分支:用于保证系统的完整性,与PRO分支除数据库配置文件不同外,必须完全一致。

GIT分支:由开发工程师根据需求所建的分支,由开发工程师从本地GIT 资源库推送至公司统一的GIT版本资源库。

测试分支:由项目组自行定义的分支,用于管理测试环境的代码版本库,可根据业务部门的用户需求自行合并GIT分支进行打包整合,以提供给BU部门稳定的可用的测试环境。

2GIT操作使用说明2.1 GIT工具的安装及权限开放申请1.GTI插件在ECLIPSE软件的安装及引用:官网下载当前最新版的GIT插件,并放置于ECLIPSE项目插件结构下,ECLIPSE工具安装插件方法可参照官网上相应的教程:/egit/updates/2.配置SSH登陆口令:ECLIPSE程序中,Window->Preferences->输入SSH进行配置定位查询。

Git提交备注规范

Git提交备注规范

Git提交备注规范原⽂:feat:新增 featurefix: 修复 bugdocs: 仅仅修改了⽂档,⽐如 README, CHANGELOG, CONTRIBUTE等等style: 仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑refactor: 代码重构,没有加新功能或者修复 bugperf: 优化相关,⽐如提升性能、体验test: 测试⽤例,包括单元测试、集成测试等chore: 改变构建流程、或者增加依赖库、⼯具等revert: 回滚到上⼀个版本Git分⽀与版本发布规范基本原则:master为保护分⽀,不直接在master上进⾏代码修改和提交。

开发⽇常需求或者项⽬时,从master分⽀上checkout⼀个feature分⽀进⾏开发或者bugfix分⽀进⾏bug修复,功能测试完毕并且项⽬发布上线后,将feature分⽀合并到主⼲master,并且打Tag发布,最后删除开发分⽀。

分⽀命名规范:分⽀版本命名规则:分⽀类型 _ 分⽀发布时间 _ 分⽀功能。

⽐如:feature_20170401_fairy_flower分⽀类型包括:feature、 bugfix、refactor三种类型,即新功能开发、bug修复和代码重构时间使⽤年⽉⽇进⾏命名,不⾜2位补0分⽀功能命名使⽤snake case命名法,即下划线命名。

Tag包括3位版本,前缀使⽤v。

⽐如v1.2.31。

Tag命名规范:新功能开发使⽤第2位版本号,bug修复使⽤第3位版本号核⼼基础库或者Node中间价可以在⼤版本发布请使⽤灰度版本号,在版本后⾯加上后缀,⽤中划线分隔。

alpha或者belta后⾯加上次数,即第⼏次alpha:v2.0.0-alpha.1v2.0.0-belta.1版本正式发布前需要⽣成changelog⽂档,然后再发布上线。

Git使用规范

Git使用规范

Git使⽤规范1.git 基本操作- git init 如果⼀个项⽬需要使⽤ git 进⾏托管,需要初始化- git status 查看当前代码的状态 (红⾊:在开发区,绿⾊:在暂存区,nothing to commit:开发区没有任何变更) - git checkout -b develop 创建并切换到【开发基准分⽀ develop】- git checkout -b feature/xxxx 基于 develop 创建功能分⽀,功能分⽀建议以 feature/ 开发- git add . 将代码放到暂存区- git commit -m 功能名称将代码从暂存区放到本地仓库- git checkout 分⽀名切换到某⼀个分⽀- git merge feature/xxxx 就是分⽀合并到另⼀个分⽀- git push 将本地仓库的代码推送到远程- git pull 将远程主机的最新内容拉下来后直接合并- git fetch 将远程仓库的最新内容拉到本地,⽤户在检查了以后决定是否合并到⼯作本机分⽀中- git log 查看⽇志- git log --oneline 查看简洁版⽇志(推荐)- git reset --hard xxx 还原到某⼀个节点,节点是提交的某个 commit,需要使⽤ git log 查看2.注意事项- 不能够在 master 、develop 写任何代码、修改任何 bug,开发中禁⽌- develop 需要基于 mater 进⾏创建,如果 develop 代码出现了问题,也是需要基于 mater 重建- 所有的功能分⽀,必须基于 develop 进⾏创建,develop 应该包含所有的功能分⽀- 分⽀与分⽀之间,禁⽌相互合并,包括可能会涉及到测试分⽀、预发布上线分⽀等等等……- 如果 develop 代码出现了 bug,禁⽌在 develop 分⽀中直接修改,需要创建 bugfix 分⽀修改- release 分⽀是预发布分⽀①它包括所有新的功能和必要的修复②它已经被彻底的测试过了。

gitflow的使用流程和规范

gitflow的使用流程和规范

Gitflow的使用流程和规范简介Gitflow是一种在Git版本控制系统中使用的工作流程模型,它提供了一种有条理而结构化的方式来管理代码分支,适合中大型开发团队使用。

本文将介绍Gitflow的基本使用流程和规范。

使用流程Gitflow基于两个长期分支(main和develop)以及多个短期分支进行工作。

下面是Gitflow的主要使用流程:1.创建主分支:首先,我们需要在Git仓库中创建两个主要分支,即main和develop。

通常,main主分支用于稳定版本的发布,而develop分支用于集成所有功能的开发。

2.功能开发分支:当需要开发某个新功能时,我们从develop分支创建一个新的功能分支。

命名规范建议以功能名为前缀,例如feature/login。

3.开发新功能:在功能分支上进行新功能的开发和测试。

这是一个短期分支,只用于开发特定的功能。

4.完成开发:当新功能开发完成并通过测试后,我们将其合并回develop分支。

这意味着新功能已经被集成到了整个项目中。

5.发布准备分支:当develop分支中积累了足够多的功能,我们可以创建一个发布准备分支。

此分支用于准备即将发布的版本,可以进行最后的调试、测试和版本号更新等操作。

6.发布版本:当发布准备分支已经完成并通过测试时,我们将其合并回main分支,并给该版本分配一个唯一的版本号。

这意味着该版本已经正式发布。

7.维护分支:在发布版本后,我们可能需要继续对已发布版本进行Bug修复或者发布新的小版本。

这时,我们从main分支创建一个维护分支,以提供对发布版本的长期维护支持。

规范为了使Gitflow工作流正常运行且易于管理,以下是一些Gitflow的规范建议:•分支命名规范:分支的命名应该有一定的规范,以便于说明分支所代表的功能或操作。

例如,使用feature/前缀表示功能分支,hotfix/前缀表示Bug修复分支。

•提交信息规范:每个提交都应该附带一个有意义的提交信息,描述提交所做的更改。

Git提交规范及使用说明

Git提交规范及使用说明

Git提交规范及使用说明一.Git提交规范一次提交包含四个信息:commit message -提交的内容相关描述author & committer -作者及提交者changed files -修改的文件hash & parent -提交内容的hash及在提交树上的位置1.提交信息一般包括<header><body><footer>三部分。

<header>是必须的,一般在50个字符之内,其结构为:(其中<scope>可以不写)<type>(<scope>): <short summary>│││││└─⫸ Summary in present tense. Not capitalized. No period at the end.│││└─⫸ Commit Scope:animations|bazel|benchpress|common|compiler|compiler-cli|core...│└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test<type>表明本次提交的类型,一般有如下几种:build: 涉及构建相关的改动ci: 持续集成相关的改动docs: 文档feat: 新功能fix: bug修复perf: 性能相关改动refactor: 重构相关(非bug、非新功能)test: 测试相关,包括新增测试或者更改已有测试<summary>使用现在时或祈使句。

<body>提交信息的更为详细的描述,与<header>一样也是用祈使句、现在时。

<body>描述本次修改的动机,比如为什么引入本次改动,之前的逻辑是什么,现在的逻辑是什么,本次改动有哪些影响,等等。

前端规范之Git提交规范(Commitizen)

前端规范之Git提交规范(Commitizen)

前端规范之Git提交规范(Commitizen)代码规范是软件开发领域经久不衰的话题,⼏乎所有⼯程师在开发过程中都会遇到或思考过这⼀问题。

⽽随着前端应⽤的⼤型化和复杂化,越来越多的前端团队也开始重视代码规范。

同样,前段时间,笔者所在的团队也开展了⼀波开源治理,⽽其中代码规范就占据了很重要的⼀项。

接下来的⼏篇⽂章,将会对JS代码规范、CSS规范、Git提交规范以及Git⼯作流规范进⾏详细的介绍~系列⽂章:本⽂主要介绍了前端规范之Git提交规范(Commitizen),将会对Commitizen的使⽤进⾏介绍,欢迎⼤家交流讨论~1. 背景Git是⽬前世界上最先进的分布式版本控制系统,在我们平时的项⽬开发中已经⼴泛使⽤。

⽽当我们使⽤Git提交代码时,都需要写Commit Message提交说明才能够正常提交。

git commit -m "提交"然⽽,我们平时在编写提交说明时,通常会直接填写如"fix"或"bug"等不规范的说明,不规范的提交说明很难让⼈明⽩这次代码提交究竟是为了什么。

⽽在⼯作中,⼀份清晰简介规范的Commit Message能让后续代码审查、信息查找、版本回退都更加⾼效可靠。

因此我们需要⼀些⼯具来约束开发者编写符合规范的提交说明。

2. 提交规范那么,什么样的提交说明才能符合规范的说明呢?不同的团队可以制定不同的规范,当然,我们也可以直接使⽤⽬前流⾏的规范,⽐如。

接下来将会对⽬前流⾏的Angular提交规范进⾏介绍。

2.1 提交格式符合规范的Commit Message的提交格式如下,包含了页眉(header)、正⽂(body)和页脚(footer)三部分。

其中,header 是必须的,body和footer可以忽略。

<type>(<scope>): <subject>// 空⼀⾏<body>// 空⼀⾏<footer>2.2 页眉设置页眉(header)通常只有⼀⾏,包括了提交类型(type)、作⽤域(scope)和主题(subject)。

Git规范化提交

Git规范化提交

Git规范化提交一、前言在开发团队协作中,“开发规范” 是经常被讨论的话题。

当然,除了代码上的规范,还有一个很重要的规范就是“提交规范”。

规范化提交的目的:•提交统一的、有规则的信息;而不是混乱的、看不懂是什么意思的信息•可以提供更加明朗的历史信息,便于后续快速定位问题、代码回滚等的操作•可以自动化生成changelog二、huskyhusky是一个 Git-Hooks 工具. 那么 hooks 是什么呢?“hooks” 直译是“钩子”,它并不仅是 react,甚至不仅是前端界的专用术语,而是整个行业所熟知的用语。

通常指:系统运行到某一时期时,会调用被注册到该时机的回调函数。

规范化提交第一步就是要在git commit之前先做一次Lint校验,限制不规范代码的提交,那husky这个工具就能做到。

husky继承了Git下所有的钩子,在触发pre-commit钩子的时候,阻止不合法的 commit、push 等等。

2.1 初始化 git 目录如果没有先初始化 git,需要重新装husky。

git init -y2.2 安装 husky# pnpm 安装pnpm add husky -D-w# or npm 安装npm install husky -D2.3 添加 husky 脚本在package.json文件 scripts 中手动添加"prepare": "husky install"或者直接执行命令添加npm set-script prepare "husky install"prepare 脚本会在npm install(不带参数)之后自动执行。

也就是说当我们执行npm install安装完项目依赖后会执行 husky install命令,该命令会创建.husky/目录并指定该目录为git hooks所在的目录。

2.4 执行 npm run prepare执行之后会发现项目根目录多了个.husky的目录及文件。

gitcommit提交规范和规范校验

gitcommit提交规范和规范校验

gitcommit提交规范和规范校验⼀、⽬的在多⼈协作项⽬,如果代码风格统⼀、提交信息准确,那么在后期协作以及BUG处理时会更加⽅便。

格式化的commit message有以下⼏个好处:1. ⽅便快速检索历史提交信息,只看⾏⾸即可知晓commit的⽬的git log HEAD --pretty=format:%s2. 可以过滤某些commit(⽐如⽂档更新),便于快速查找信息git log HEAD --pretty=format:%s --grep 新功能3. 可以直接从commit⽣成changelog,说明与上⼀版本发布的差异通过changelog,测试知晓本次变更修改范围⼆、格式每⼀次提交,信息都必须遵循commit信息格式,包含Header、Body、Footer三个部分。

commit信息格式三、⼯具3.1 依赖安装# 安装所需依赖, changelog-sn⾄少2.x版本npm install -D changelog-sn standard-version3.2 配置commitlint和commitizen代码仓库根⽬录创建⽂件.commitlintrc.js和.czconfigrc.js3.2.1 配置.commitlintrc.js内容module.exports = Object.assign({}, require('changelog-sn/lib/lint'), {rules: {'subject-empty': [2, 'never'],'type-empty': [2, 'never'],'scope-empty': [2, 'never'],'type-enum': [2,'always',['新功能','修复','优化','重构','⽂档','chore','revert','WIP','docs','build','release']]}})3.2.2 配置.czconfigrc.jsmodule.exports = {types: [{ value: '新功能', name: '新功能 : 新增加⼀个功能' },{ value: '修复', name: '修复 : ⼀个 bug 修复' },{ value: '优化', name: '优化 : 提升性能的代码更改' },{ value: '重构', name: '重构 : 不涉及修复bug和新功能开发的代码更改' },{ value: '⽂档', name: '⽂档 : 只有⽂档发⽣改变' },{ value: 'chore', name: '构建 : 修改持续集成的配置⽂件和脚本' },{ value: 'revert', name: '撤销 : 撤销⼀个历史提交' },{ value: 'WIP', name: '待完成 : 研发中的提交备份' }],messages: {type: '选择你提交的信息类型:',scope: '选择本次提交的改变所影响的范围?',customScope: '本次提交的改变所影响的范围?',subject: '写⼀个简短的变化描述,尽量包含主谓宾结构,杜绝简单的单词:\n',body: '提供更详细的变更描述 (按 enter 跳过). 使⽤ "|" 换⾏:\n',breaking: '列出所有的不兼容变更 (按 enter 跳过):\n',footer: '列出此次改动解决的所有 issues (如:"#123, #234")(按 enter 跳过):\n',confirmCommit: '确认提交以上内容信息?'},allowBreakingChanges: ['refactor', 'chore'],breakingPrefix: 'WARNING:',skipQuestions: ['body'],subjectLimit: 100,breaklineChar: '|',footerPrefix: 'CLOSED:'}3.2.3 配置package.json{"scripts": {"log": "changelog-sn -i CHANGELOG.md -s -r 2","cz": "git add . && git cz"},"husky": {"hooks": {"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}},"config": {"commitizen": {"path": "./node_modules/cz-customizable"},"cz-customizable": {"config": "./.czconfigrc.js"}},"devDependencies": {"changelog-sn": "2.0.5"}}作者:逆黄链接:https:///p/d20ecbc66ae1来源:简书著作权归作者所有。

gitcommit提交规范

gitcommit提交规范

gitcommit提交规范<type>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>⼤致分为三个部分(使⽤空⾏分割):1. 标题⾏: 必填, 描述主要修改类型和内容2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等3. 页脚注释: 放 Breaking Changes 或 Closed Issuestype: commit 的类型init: 初始化feat: 新特性fix: 修改问题refactor: 代码重构docs: ⽂档修改style: 代码格式修改, 注意不是 css 修改test: 测试⽤例修改build: 构建项⽬chore: 其他修改, ⽐如依赖管理scope: commit 影响的范围, ⽐如: route, component, utils, build...subject: commit 的概述body: commit 具体修改内容, 可以分为多⾏.footer: ⼀些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.⽰例fix(修复BUG)如果修复的这个BUG只影响当前修改的⽂件,可不加范围。

如果影响的范围⽐较⼤,要加上范围描述。

例如这次 BUG 修复影响到全局,可以加个 global。

如果影响的是某个⽬录或某个功能,可以加上该⽬录的路径,或者对应的功能名称。

// ⽰例1fix(global):修复checkbox不能复选的问题// ⽰例2 下⾯圆括号⾥的 common 为通⽤管理的名称fix(common): 修复字体过⼩的BUG,将通⽤管理下所有页⾯的默认字体⼤⼩修改为 14px// ⽰例3fix: value.length -> values.lengthfeat(添加新功能或新页⾯)feat: 添加⽹站主页静态页⾯这是⼀个⽰例,假设对页⾯内容进⾏了⼀些描述。

Git提交日志规范

Git提交日志规范

Git提交⽇志规范1. 为什么需要规范的提交信息?在团队协作中,使⽤ Git、SVN 等这些版本管理⼯具。

当我们提交代码的时候,往往需要编写提交信息(commit message)。

⽽提交信息的主要⽤途是:告诉这个项⽬的⼈,这次代码提交⾥做了些什么。

⼀般来说,建议⼩步提交,即按⾃⼰的任务步骤来的提交,每⼀⼩步都有对应的提交信息。

这样做的主要⽬的是:防⽌⼀次修改中,修改过多的⽂件,导致后期修改、维护、撤销等等困难。

2. 参考与我们⽇常⼯作稍有不同的是:⼯作中的 Release 计划⼀般都是事先安排好的,不需要⼀些 CHANGELOG 什么的。

⽽开源项⽬需要有对应的 CHANGELOG.md ,则添加了什么功能、修改了什么等等。

毕竟有很多东西是由社区来维护的。

Angular 团队建议采⽤以下的形式:提交消息头Message header<BLANK LINE> //空⾏<body> // 提交具体内容<BLANK LINE>//空⾏<footer> // 额外内容其中 Header 是必须的, body,footer 是可选的例⼦在最后2.1 提交消息头 (commit message header)<type> , ⽤于以下类型说明提交类型:build: 影响构建系统或外部依赖关系的更改(⽰例范围:gulp,-broccoli,npm)ci: 更改我们的持续集成⽂件和脚本(e.g.: Travis,GitLab 等)docs: 仅⽂档更改feat: ⼀个新功能fix: 修复错误perf: 改进性能的代码更改refactor: 代码更改,既不修复错误也不添加功能style: 不影响代码含义的变化(空⽩,格式化,缺少分号等)test: 添加缺失测试或更正现有测试chore: 构建过程或辅助⼯具的变动release: 版本发布revert: 特殊情况,当前 commit ⽤于撤销以前的 commit<scope>, 说明 commit 影响的范围最好是指定提交更改位置 (结构的), 例如$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等等没有合适的范围可以使⽤*<subject>, 此次提交的简短描述, 不应超过 50 个字符以动词开头,使⽤第⼀⼈称现在时,⽐如change,⽽不是changed或changes第⼀个字母⼩写结尾不加句号(.)类型实例没有指定scopetest: fix ts api guardian and public guard tests on windows (#30105)2.2 提交消息具体内容 (commit message body)<body> , 可选的, 此次提交详细描述, 如果需要⽤到 body, 则应注意以下两点以动词开头,使⽤第⼀⼈称现在时,⽐如change,⽽不是changed或changes实例More detailed explanatory text, if necessary. Wrap it toabout 72 characters or so.Further paragraphs come after blank lines.- Bullet points are okay, too- Use a hanging indent2.3 提交消息尾述 (commit message footer)<footer> , 可选的, 此次提交描述的补充, 通常有两种情况不兼容的变动, 如果当前代码与上⼀个版本不兼容,则 Footer 部分以BREAKING CHANGE:开头,后⾯是对变动的描述、以及变动理由和迁移⽅the inject option for the directive controller injection was >removed.To migrate the code follow the example below:Before:scope: {myAttr: 'attribute',myBind: 'bind',myExpression: 'expression',myEval: 'evaluate',myAccessor: 'accessor'}After:scope: {myAttr: '@',myBind: '@',myExpression: '&',// myEval - usually not useful, but in cases where the >expression is assignable, you can use '='myAccessor: '=' // in directive's template change >myAccessor() to myAccessor}Issue, 需要关闭⼀个或多个某个 issue3. Git 获取提交消息格式化输出获取提交列表message headergit log <last tag> HEAD --pretty=format:%s// 2. 过滤类型 typegit log <last release> HEAD --grep feature// 3. 跳过⼀些⽆关紧要的提交git bisect skip $(git rev-list --grep irrelevant <good place> HEAD)4. 与此同时还有⼀个名为 Conventional Commits 的规范,建议采⽤相似的形式。

Git项目提交规范结合Husky+commitlint使用

Git项目提交规范结合Husky+commitlint使用

Git项⽬提交规范结合Husky+commitlint使⽤⼀、前置条件 为了更好地 GIT 提交,加⼊了代码提交规范和规范校验,优雅的提交; ⽅便团队协作和快速定位问题,采取Husky + commitlint辅助项⽬做约定。

npm install --save-dev husky For windows install commintlint: npm install --save-dev @commitlint/config-conventional @commitlint/cli⼆、配置 // 命令⽣成配置⽂件 commitlint.config.js 或.commitlintrc.js echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js package.json 添加commitlint配置项:"husky": {"hooks": {"pre-commit": "npm run lint","commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"}} husky是git hook⼯具,⽂件格式 .huskyrc,它能帮你阻挡不好的代码提交和推送; (pre-commit 钩⼦命令⽤于提交前运⾏检查,看项⽬情况决定要不要使⽤, "pre-commit": "lint-staged" 扩展使⽤lint-staged库辅助,或者是⾃定义lint, "lint": "eslint src --fix --ext .ts,.tsx " ) 或者创建⽂件 .lintstagedrc (如果⽆pre-commit限制,使⽤ --no-verify eg: git commit --no-verify -m 'feat: 增加 xxx 功能')三、定制提交规范 1.提交格式(冒号后⾯有空格):'<type>[scope]: <subject>' // eg: git commit -m 'feat: 增加什么功能' type|subject 必选,scope 可选; scope 可省略,⽤于说明commit的影响范围和模块; subject 是commit的⽬的简短描述,可以配置最⼤长度限制,配置72字符; 2.常⽤type类型:'build' 项⽬构建的提交(eg:webpack配置等)'upd' 更新某个功能'feat'新功能(feature)'fix'修补bug'refactor'重构代码(不是新增也不是修补代码)'style'不影响程序逻辑的改动(eg:格式)'perf'性能优化'revert'回滚到某个更早的提交'docs'⽂档更新'chore' 其他类型(eg:构建过程或辅助⼯具的变化)'test'增加测试⽤例 3. commitlint config rules level: 0为disable,1为warning,2为error; 第⼆位: 'always'或'never'; 第三位: 值 4.配置图如下:四、范例 终端(开发分⽀)步骤: git add . -> git commit –no-verify –m ‘upd: 更新某个功能’-> git push github desktop /vscode git管理/TortoiseGit客户端: 暂存更改 -> 描述(upd: 更新某个功能) commit -> push/fetch。

规范gitcommit格式

规范gitcommit格式

规范gitcommit格式安装 commitizen 插件来实现[TOP]最近在学习规范使⽤git开发,发现⼀个⽐较好⽤的来规范comment的⼯具,记录⼀下,⼀般来说,commit message 应该清晰明了,说明本次提交的⽬的,所以需要⼀些规范来使这些comment变得可读.commitizen则是最近发现的⼀款⽐较易⽤的⼯具git的提交使⽤git commit -m "hello world"来提交comment,但是⼀些像hello world这样没有意义的comment让⼈⽆法理解这次的提交到底是为了什么下⾯是⼀些基础介绍如果觉得⿇烦直接查看第⼆部分1. commit message format(信息域)commit message⼀般分为三个部分Header,Body 和 Footer<type>(<scope>): <subject>// 空⼀⾏<body>// 空⼀⾏<footer>其中,Header 是必需的,Body 和 Footer 可以省略Example:PS D:\git\pythonPractice> git logcommit 58a7a966acb9aa2fffc0e02c9ce3be64b8949991 (HEAD -> master)Author: Zhiwei Tian <hebeitianzhiwei@>Date: Fri Aug 17 17:38:36 2018 +0800feat(serve): add grpc server1.1 HEADtype⽤于说明commit的类别,只允许使⽤下⾯7个标识feat:新功能(feature)fix:修补bugdocs:⽂档(documentation)style:格式(不影响代码运⾏的变动)refactor:重构(即不是新增功能,也不是修改bug的代码变动)test:增加测试chore:构建过程或辅助⼯具的变动scope⽤来说明本次Commit影响的范围,即简要说明修改会涉及的部分,⽐如数据层、控制层、视图层等,subject comment所在的位置,这次提交的简短描述1.2 Body 是对本次 commit 的详细描述,可以分成多⾏1.3 Footer 部分只⽤于两种情况不兼容变动如果当前代码与上⼀个版本不兼容,则Footer部分以BREAKING CHANGE开头,后⾯是对变动的描述、以及变动理由和迁移⽅法关闭 Issue如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue (可依次关闭过个issue Closes #123, #245, #992)1.4 Revert还有⼀种特殊情况,如果当前 commit ⽤于撤销以前的 commit,则必须以revert:开头,后⾯跟着被撤销 Commit 的 Headerrevert: type(scope): some commentThis reverts commit bfe307ce57d87677c6c473c228e6c2ed8b81dcec.Body部分的格式是固定的,必须写成This reverts commit <hash>.,其中的hash是被撤销 commit 的HSHA标识符。

git提交规范

git提交规范

git提交规范
git提交规范是指关于如何使用git提交到版本库准确、可读、易追踪的规则。

一般
都包括 git commit message 的格式、git workflow 的选择以及审批机制等内容。

首先,在使用git提交之前,需要遵循一定的提交规则,例如:
- 提交注释要有意义:提交注释应该以自然语言形式进行描述,而不是仅仅使用程序
代码描述。

- 提交注释要准确:要避免模糊的描述,以尽量详细的描述代码的具体细节。

- 尽量拆分不同功能的提交:不要把不同的代码整合到一次提交中,应该尽量使用多
次提交来分隔不同功能。

- 使用可读性高的缩写:需要使用更加简短、可读性高的缩写来描述每个提交。

- 尽量为每个commit使用单个文件夹:这样可以更清楚的描述每个提交的状态。

在提交之后,为了更好的保证版本的质量,还需要设置审批机制:在提交代码之前,
需要一名审批人进行检查,以确保代码的质量和安全性。

此外,还需要考虑合适的git workflow,例如Github Flow、Gitlab Flow或者Git flow等,以达到最佳的开发流程。

根据不同的项目,选择合适的git workflow更有利于
减轻沟通问题以及整合仓库中不同提交过程等。

以上就是git提交规范的基本内容,按照此规则使用git可以更有效地管理代码版本,保证项目的可维护性和可追踪性。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Git 版本控制
Git中大部分操作都是针对本地文件和本地数据库,只有在我们平时执行类似克隆(clone)、pull、push等命令时才与远程服务器交互。

这样对于开发维护代码库就很安全,因为一旦远程服务器代码丢失仍然可以将本地代码上传到服务器;也会给开发者带来诸多方便,因为将远程代码取到本地后可以随意的修改,一旦修改混乱之后仍然可以恢复到以前版本,即使本地代码被误删除仍然可以重新从服务器取回代码。

下面将针对一些常用使用命令和技巧进行介绍:
一、git提交规范
在commit是,如果有对应PR,请在第一行写上PR号,然后再描述信息(另起行),并把涉及到改动的文件名附上.
具体操作如下(不用git commit -m 填写说明):
1、如果提交全部文件(请先git status确认是否要提交所有改动)
1.1 git commit -a
1.2 在打开的编辑器中(默认为VIM) 第一行填写PR号(顶格写,多个
PR用逗号隔开,要写全),然后再写说明。

1.3 把涉及修改文件路径前的# 去掉,就会提交,不用手工输入文件路径。

1.4 然后ESC 输入:wq退出VIM.
2、如果提交部分文件
2.1 分别git add 要提交的所有文件。

2.2 git commit。

2.3 以后步骤同上。

二、第一次初始配置
1、第一次取出代码到本地需要克隆代码(从服务器取代码到本地),一般如果新建一个本地代码库都需要重新克隆一次代码。

命令:git clone git://服务器代码库地址
2、第一次使用git环境一般应该配置你的用户信息,这样会方便别人与自己查看git提交代码记录。

命令:$ git config --global zhangsan
$ git config --global user.email *****************.cn
这里使用的—global,以后的所有项目都默认使用这个配置,这时写入的是用户主目录的git配置文件(跟曲以鹏在邮件里边说的那个“.gitconfig”文件应该是一回事),如果想改变其中一个项目的配置可以去掉—global重新配置如:
命令:$ git config lisi
查看这些配置信息,如:
命令:$ git config --list
3、修改编辑器,一般我们在git commit(提交)后,需要添加PR号或者添加注释信息,对于编辑可以选用自己习惯的编辑器如:vi
命令:$ git config --global core.editor vi
三、提交代码(这部分只是针对本地代码库,所有操作都没有涉及服务器)
1、提交代码过程大家都非常熟悉,平时常用几种命令,如:
$ git add file –> $ git commit 或者全部提交:$ git commit –a
当中可能经常使用如$ git status 查询状态、$ git diff 比较不同。

下面总结了一些以上过程中比较、撤销等好用命令。

2、本地操作代码库状态
本地操作后,本地代码库会有三种状态:修改、暂存、提交。

修改暂存提交
Git add Git commit
Git add 后就从修改变为暂存,git commit 后就从暂存变为提交。

1)、各个状态比较命令如:
修改与暂存比较不同:$ git diff <文件路径>
暂存与上次提交比较不同:$ git diff --cached <文件路径>
2)、将文件从暂存移除变为修改状态,一般git add后发现添加文件多了,可以使用命令如:
$ git reset HEAD <file路径>
3)、修改提交文件,代码提交以后会产生一个哈希值类似(a124b9da6552252987aa493b52f8696cd6d3b003)一字符串,以后可以根据哈希值回到相应版本。

对于刚刚提交的代码很容易忘记写注释(PR)或者漏提交了部分文件,这时可以使用命令修改上次的提交:$ git commit --amend
如果添加注释可以直接执行命令,填写注释保存。

如果添加文件先执行$ git add 后执行$ git commit –amend
3、查看以前提交情况
1)、查看某人提交日志
命令:$ git log --author=zengyun
2)、搜索提交日志(根据第一行的PR号)
命令:$ git log --grep=PR000667740
这里边的PR号一定在第一行写,如果多个PR号请用‘,’隔开。

具体请参考git 提交规范。

3)、查看某文件夹log
命令:$ git log framework/base/core/java/android/
4)、查看每次提交信息
命令:$ git log -p -2
-2表示最近两次提交。

5)、查看某次提交的详细信息
命令:$ git show 5ba47ce9ceb4c5db86563c03c6833ee47bd22a53
6)、如果精确查找显示可以将上面1)、2)、3)、4)组合使用。

四、远程服务器取、推代码。

(与服务器交互)
前面提过克隆命令:git clone git://服务器,它实现过程实际上是创建本地分支master,并且去服务器代码到本地。

1、取代码从服务器命令:$ git pull
2、推代码到服务器命令:$ git push
在主分支下,不用指定分支名称,系统会默认为pull主分支。

五、切换到分支下工作
目前各种定制越来越多,作为使用者如何直接进入分支,开展我们的开发工作。

下面以印度分支为例进行说明:
1、克隆代码,
命令:git clone git://192.168.1.231/home/android/workspace/App7627_5330
注:(如果本地有代码则没有此步)
2、确定当前分支所在,
命令:git branch
例如:
Inida_MMX
* master
表示当前所在分支是主分支master
3、如果第一次克隆代码,使用git branch查询时候发现只有master分支,在切换到India_MMX分支时候,
需要执行命令:git checkout origin/India_MMX
之后会有提示,然后再执行下面命令:git checkout -b India_MMX
4、如果印度分支已经存在,具体方法如下:
命令:git checkout India_MMX
六、分支下常用命令
1、pull代码
命令:git pull origin India_MMX
push提交代码
命令:git push origin India_MMX
2、切换到主分支
命令:git checkout master
如果切换的过程出现merge失败,使用$ git status命令查看哪些文件不能merge,之后手动merge。

3、查看所有分支(服务器与本地)
命令:$ git branch –a
4、查看当前分支下最新提交信息
命令:$ git branch –v。

相关文档
最新文档