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 分⽀是预发布分⽀①它包括所有新的功能和必要的修复②它已经被彻底的测试过了。

  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。

相关文档
最新文档