gerrit git 常用操作 - 360文档中心

gerrit的工作流程

gerrit的工作流程Gerrit的工作流程Gerrit是一个基于Git的代码审查工具，广泛应用于软件开发中。

它提供了一个便捷的方式来进行代码审查和团队协作，可以帮助开发者更好地管理和维护代码库。

本文将详细介绍Gerrit的工作流程，帮助读者了解和掌握如何使用这个强大的工具。

一、创建变更在使用Gerrit进行代码审查之前，首先需要创建一个变更。

变更是指对代码库进行的一次修改，可以是新增、修改或删除文件。

开发者可以通过Git命令来创建一个变更，并提交到Gerrit服务器上。

二、上传变更一旦创建了变更，开发者就可以将其上传到Gerrit服务器上进行审查。

上传变更的方式有多种，可以通过命令行工具，也可以通过Gerrit提供的Web界面来完成。

上传变更后，Gerrit会为每个变更生成一个唯一的变更号，并将其显示在变更列表中。

三、代码审查上传变更后，团队成员可以对其进行代码审查。

代码审查是指对代码进行仔细的检查和评估，以确保代码的质量和可维护性。

在Gerrit中，代码审查是通过评论的方式进行的。

团队成员可以在代码的每个行或者代码块上添加评论，提出问题或者给出建议。

这些评论可以帮助开发者改进代码，并最终达到更好的代码质量。

四、处理反馈一旦团队成员对变更提出了评论，开发者就可以根据这些反馈来进行代码的修改。

开发者可以根据评论的内容，对代码进行相应的调整和改进，以满足审查人员的要求。

在Gerrit中，开发者可以通过提交新的变更来响应审查人员的反馈，也可以在原有的变更上进行修改并重新上传。

五、重新审查在开发者对变更进行了修改后，团队成员需要重新审查代码。

他们可以查看开发者对评论的回复，并对修改后的代码进行再次评估。

如果团队成员对修改后的代码满意，他们可以在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。

gerrit使用git review提交

gerrit使用git review提交摘要：1.Gerrit 简介2.Git Review 的使用3.Gerrit 与Git Review 的结合4.使用Gerrit 提交Git Review 的具体步骤5.注意事项正文：一、Gerrit 简介Gerrit 是一个免费的、开源的代码审查工具，它可以帮助团队更有效地进行代码审查，以提高代码质量和安全性。

Gerrit 是基于Web 的，可以与Git 等版本控制系统集成，提供便捷的代码审查功能。

二、Git Review 的使用Git Review 是Git 提供的一个命令行工具，用于对本地仓库中的更改进行审查。

通过Git Review，开发者可以在将更改推送到远程仓库之前，先让审查者检查代码。

这有助于确保代码质量，并减少在合并代码时出现的冲突。

三、Gerrit 与Git Review 的结合Gerrit 可以与Git Review 结合使用，以实现更高效的代码审查。

通过将Git Review 的命令集成到Gerrit 中，开发者可以在Gerrit 界面中直接使用Git Review 的功能，而无需在命令行中执行Git Review 命令。

四、使用Gerrit 提交Git Review 的具体步骤1.首先，确保你的本地仓库已经与Gerrit 服务器进行了关联。

2.在本地仓库中，使用`git add`和`git commit`命令将更改添加到暂存区，并提交更改。

3.在Gerrit 界面中，点击“Submit a Change”按钮，打开提交更改的对话框。

4.在对话框中，选择“Git Review”选项卡，输入审查者的Git 用户名和邮箱地址。

5.点击“Submit”按钮，将更改提交给审查者进行审查。

6.审查者将通过Git Review 工具对代码进行审查，并在Gerrit 界面中留下审查意见。

7.开发者可以根据审查意见对代码进行修改，并重新提交给审查者进行审查。

gerrit使用实例

gerrit使用实例摘要：1.Gerrit简介与安装2.Gerrit基本功能与操作3.Gerrit分支策略与管理4.Gerrit代码审查与审批5.Gerrit插件与扩展6.实践中的Gerrit优化与配置7.Gerrit在国内的应用案例8.总结与展望正文：一、Gerrit简介与安装Gerrit是一款基于Web的代码审查和版本控制系统，起源于Google的内部项目。

它与Git紧密结合，允许开发者在代码提交后进行审查，以确保代码质量。

在本节中，我们将介绍Gerrit的安装过程及其基本概念。

1.安装Gerrit首先，你需要确保你的系统满足Gerrit的最低需求，如Python、Java 和Git等。

然后，你可以从Gerrit官方下载对应操作系统的安装包，并根据安装向导完成安装。

2.配置Gerrit在安装完成后，你需要对Gerrit进行基本配置，包括：设置数据库、配置SSH密钥、开启Web界面等。

详细配置过程可参考Gerrit官方文档。

3.Gerrit基本概念Gerrit主要有以下几个概念：- 项目（Project）：Gerrit中的基本组织单位，包含多个分支。

- 分支（Branch）：项目中的代码版本，每个分支代表一个独立的开发进度。

- 提交（Commit）：代码变更的单元，包含代码和提交信息。

- 代码审查（Code Review）：Gerrit的核心功能，审查者在代码提交后进行审核，给出意见和建议。

二、Gerrit基本功能与操作在了解Gerrit的基本概念后，我们可以开始学习Gerrit的具体操作。

1.创建分支在Gerrit中，你可以通过Web界面或命令行创建分支。

创建分支后，你可以在此分支上进行开发。

2.提交代码将代码上传至Gerrit仓库，生成提交。

提交时，建议附带详细的提交信息，以便于审查者了解代码变更目的。

3.发起代码审查在提交代码后，你可以将代码审查请求发送给审查者。

审查者可以在Gerrit Web界面查看代码，并给出意见和建议。

Gerrit的基本使用

Gerrit的基本使⽤1、Gerrit的基本介绍Gerrit 是⼀个Git服务器，它基于 git 版本控制系统，使⽤⽹页界⾯来进⾏审阅⼯作。

Gerrit 旨在提供⼀个轻量级框架，⽤于在代码⼊库之前对每个提交进⾏审阅，更改将上载到 Gerrit，但实际上并不成为项⽬的⼀部分，直到它们被审阅和接受。

代码审查是Gerrit的核⼼功能，但仍是可选的，团队可以决定不进⾏代码审查⽽⼯作。

Gerrit 是⼀个临时区域, 在提交的代码成为代码库的⼀部分之前, 可以对其修改进⾏检查。

代码修改的作者将提交作为对 Gerrit 的更改。

在Gerrit中，每个更改都存储在暂存区域中，可以在其中进⾏检查和查看。

仅当它被批准并提交时，它才被应⽤到代码库中。

其实，Gerrit 就相当于是在开发员将本地修改提交到代码仓库之前的⼀个审核⼯具。

在这个审核⼯具中，你可以查看该提交者在本次的的提交中的修改，然后再决定是否可以将该修改提交给仓库。

2、Gerrit的页⾯介绍2.1、CHANGES菜单点击 changes 可以查看所在项⽬的所有审批记录，共有三种状态：open、merged、abandoned。

open：还未审核、审核不通过、审核通过还未提交到远程仓库的提交merged：审核已通过并已提交到远程仓库的提交abandoned：已取消审核的提交2.2、YOUR -> CHANGES 菜单点击 your -> changes 可以查看当前登录⽤户的名下的所有审核记录，包括本⼈提交和本⼈需审核的。

outgoing reviews：本⼈待被审核的提交incoming reviews：别⼈提交，本⼈需要审核的提交recently closed：已关闭的提交，包括已经推送到远程仓库和已经取消审核的2.3、Repositories点击 repositories 可以看到⾃⼰有权限看到的所有项⽬。

点击进⼊某个项⽬，可以查看该项⽬的下载链接，共有三种下载⽅式：anonymous http：链接⾥⾯⽆⽤户名，下载时需输⼊⽤户名和密码http：链接⾥待⽤户名，下载时⽆需输⼊⽤户名，但需要输⼊密码ssh：免密⽅式，⽆需输⼊⽤户名和密码，但需将本地⽣成的公钥保存在 Gerrit ⽹页中3、在Gerrit上的代码克隆⽅式在Gerrit上有三种克隆⽅式，如上⾯的 2.3 所⽰，跟在 github 上克隆代码没什么区别。

git+gerrit的使用手册及小技巧

1文档版本管理2GIT代码管理2.1MYSYSGIT安装2.1.1软件获取svn://192.168.1.203/project/doc/1.过程库/4.软件管理/1、版本管理软件2.1.2软件安装本地直接双击安装，一直下一步即可。

2.2G IT基本使用2.2.1登录gerrit系统获取项目克隆地址✧Gerrit地址：http://192.168.1.203/✧用户/密码：向管理员申请✧克隆地址：登录gerrit后，按照如下操作，Projects—>List—>选择克隆的项目—>点击SSH后即可发现克隆地址，见下图2.2.2项目获取方法✧登录mysysgit后生成本地ssh-key✧登录gerrit系统，按照顺序操作，Anonymous Coward —>setting—>SSHPublic Keys，复制本地公钥文件内容（一般会在生成的时候告诉路径，通常在C:\Users\baiyc\.ssh），粘贴到文档框中，添加即可✧根据上面获得克隆地址，在本地选好存放项目的路径后，在mysysgit中执行克隆即可，mysysgit中一些基本命令说明：⏹命令基本与linux命令一致⏹不一致的命令有：◆切换目录：cd /d2.2.3Git 基本操作命令git branch 查看本地所有分支git status 查看当前状态git commit 提交git branch -a 查看所有的分支git branch -r 查看本地所有分支git commit -am "init" 提交并且加注释git remote add origin git@192.168.1.119:ndshowgit push origin master 将文件给推到服务器上git remote show origin 显示远程库origin里的资源git push origin master:developgit push origin master:hb-dev 将本地库与服务器上的库进行关联git checkout --track origin/dev 切换到远程dev分支git branch -D master develop 删除本地库developgit checkout -b dev 建立一个新的本地分支devgit merge origin/dev 将分支dev与当前分支进行合并git checkout dev 切换到本地dev分支git remote show 查看远程库git add .gitrm 文件名(包括路径) 从git中删除指定文件git clone git:///schacon/grit.git 从服务器上将代码给拉下来gitconfig --list 看所有用户git ls-files 看已经被提交的gitrm [file name] 删除一个文件git commit -a 提交当前repos的所有的改变git add [file name] 添加一个文件到git indexgit commit -v 当你用－v参数的时候可以看commit的差异git commit -m "This is the message describing the commit" 添加commit信息git commit -a -a是代表add，把所有的change加到git index里然后再commitgit commit -a -v 一般提交命令git log 看你commit的日志git diff 查看尚未暂存的更新gitrma.a 移除文件(从暂存区和工作区中删除)gitrm --cached a.a 移除文件(只从暂存区中删除)git commit -m "remove" 移除文件(从Git中删除)gitrm -f a.a 强行移除修改后文件(从暂存区和工作区中删除)git diff --cached 或 $ git diff --staged 查看尚未提交的更新git stash push 将文件给push到一个临时空间中git stash pop 将文件从临时空间pop下来2.3GIT日常基本操作流程（举例）前提条件：✧在192.168.1.203 上通过gerrit已经建立一个TestGit项目（管理员操作）✧已经增加完成ssh-key（个人操作）✧设置完成用户和邮件信息（个人操作）⏹gitconfig --global "baiyunheng"⏹gitconfig --global user.email 350200139@⏹在gerrit系统中管理已经设置完成（管理员操作）2.3.1克隆项目（一）git clone ssh://baiyunheng@192.168.1.203:29418/TestGit2.3.2本地库的操作（二）✧新建里一个文件mkdirtestprojectcdtestprojectvi 1.txt✧gitadd命令cd ..git add .✧git commit命令git commit . –m “test1”说明：在以上操作完成或者之间可以使用一些查看命令⏹git status⏹git log⏹gitreflog2.3.3提交主库审核✧gitpush命令git push origin master:refs/for/master说明：第一次会报错，解决方法如下（也可以在push前执行）scp -P 29418 baiyunheng@192.168.1.203:hooks/commit-msg .git/hooks/ git commit --amend✧git pull命令git pull 拉去最新的程序2.3.4在gerrit设定审批人员✧登录gerrithttp://192.168.1.203/✧设定review人员My----》Changes 后选择你需要review的文件单击添加人员账号（例如：admin）点击Add Reviewer2.3.5Gerrit审核通过或拒绝✧在选择-2表示拒绝✧在选择+2表示通过2.3.6拒绝处理✧对源文件修改✧再提交⏹git add 1.txt⏹git commit 1.txt --amend ##一定要用amend ，为保证✧然后进行push⏹git push origin master:refs/for/master说明：一直到review通过为止，或者放弃本次修改3J ENKINS项目构建及部署访问地址：http://192.168.1.203:8081/jenkins/（如果要增加用户需要请联系管理员或者自己进行注册）使用的方法请参考例子：4其他小技巧4.1.GITIGNORE✧作用：忽略不需要提交的文件或文件夹✧具体方法如下：gitconfig --global core.excludesfile ~/.gitignore ##指定.gitignore的位置.gitignore内容可参考SVNsvn://192.168.1.203/project/doc/1.过程库/3.成果文档/1.版本管理/.gitignore内容# 忽略*.class*.class# 忽略 classes/ 目录下的所有文件classes/4.2自动添加REVIEWERA.痛苦的做法：1.git push origin HEAD:refs/for/master2. 在gerrit管理网站，每个commit一个设置reviewer.B.直接命令里面设置git push origin HEAD:refs/for/master%r=fanxu.china@其中， %r 指定了code reviewer 但这么长的一串，每次push都来上这么一次，也挺痛苦的。

Gerrit上分支操作记录（创建分支、删除分支）

Gerrit上分⽀操作记录（创建分⽀、删除分⽀）Git分⽀对于⼀个项⽬的代码管理⽽⾔，是⼗分重要的！许多久⽤git的朋友可能已经掌握的很牢固了，但对于⼀些初涉git的童鞋来说，可能还不是很熟悉。

在此，我将⾃⼰的⼀些操作经历做⼀梳理，希望能帮助到有⽤到的朋友们。

1）⾸先，利⽤gitlab进⾏创建分⽀登陆gitlab，创建组test，在这个组上创建⼯程apptest，然后让这个⼯程⾥添加内容注意：在添加内容的使⽤，我们可以⾃定义分⽀名，这个分⽀就是我们想要创建的分⽀如下截图：这样，就创建了三个分⽀：master（默认），test，dev特别注意：后⾯创建的分⽀都是以前⾯当前分⽀为源创建的所以新创建分⽀的⽂件都会包括前⾯的分⽀的⽂件，应该将和前⾯分⽀重复的⽂件删除！如：master分⽀下是testfile⽂件test分⽀下是testfile⽂件、123⽂件，应该将testfile⽂件删除dev分⽀下是testfile⽂件、123⽂件、zhonghon⽂件，应该将testfile⽂件和zhonghon⽂件删除如下：在linux客户机上操作分⽀，修改分⽀下的代码并上传到远程的git分⽀上[gerrit@115~]$ git clone git@103.10.86.30:test/apptest.git[gerrit@115~]$ git branch -av ＃查看当前分⽀情况，发现了上⾯在gitlab⾥⾯创建的三个分组master，dev，test* master 1c2ecde 12 ＃发现当前在master分⽀下（＊指向master）remotes/origin/HEAD -> origin/masterremotes/origin/dev 6eae416 234remotes/origin/master 1c2ecde 12remotes/origin/test d5b51b9 Delete zhonghogn[gerrit@115~]$ vim .gitrevirw[gerrit@115~]$ vim .testr.conf[gerrit@115~]$ git add .[gerrit@115~]$ git commit -m “add on master"[gerrit@115~]$ git push -u origin master ＃提交到master分⽀下，查看gitlab上apptest⼯程下的master分⽀，已经有这两个⽂件接着选择⼀个⾮master的分⽀，如dev分⽀，修改⾥⾯的代码[gerrit@115~]$ git branch dev remotes/origin/dev ＃先将远程gitlab上创建的分⽀在本地别名化[gerrit@115~]$ git checkout dev ＃使⽤git checkout命令切换到dev分⽀下Switched to branch 'dev'[gerrit@115~]$ git branch -av ＃查看当前分⽀，发现本地有了dev分⽀了（上⾯设置过的分⽀别名）* dev 6eae416 234master 1c2ecde 12remotes/origin/HEAD -> origin/masterremotes/origin/dev 6eae416 234remotes/origin/master 1c2ecde 12remotes/origin/test d5b51b9 Delete zhonghogn[gerrit@115~]$ vim .gitrevirw ＃修改dev分⽀下的代码[gerrit@115~]$ vim .testr.conf[gerrit@115~]$ git add .[gerrit@115~]$ git commit -m “add on dev"[gerrit@115~]$ git push -u origin dev＃注意，这⾥提交到dev分⽀下Counting objects: 5, done.Delta compression using up to 32 threads.Compressing objects: 100% (4/4), done.Writing objects: 100% (4/4), 535 bytes, done.Total 4 (delta 0), reused 0 (delta 0)To git@103.10.86.30:test/apptest.git7a4b6e6..6eae416 dev -> devBranch dev set up to track remote branch dev from origin.git push -u origin devCounting objects: 5, done.Delta compression using up to 32 threads.Compressing objects: 100% (4/4), done.Writing objects: 100% (4/4), 535 bytes, done.Total 4 (delta 0), reused 0 (delta 0)To git@103.10.86.30:test/apptest.git7a4b6e6..6eae416 dev -> devBranch dev set up to track remote branch dev from origin.这样就能push到远程的remotes/origin/dev 上了，去gitlab上看看dev分⽀下已经有了这两个⽂件.gitreview和.testr.conf如下：其他的分⽀如上⾯gitlab⾥的test分⽀，要想弄到本地，操作和上⾯的dev分⽀操作⼀样＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊线上部署了gerrit+gitlab环境（代码同步），将git代码放到上⾯进⾏维护管理了！应开发同事要求，要在他们的项⽬下创建除master默认分⽀之外的其他分⽀在gerrit上创建分⽀，这⾥我总结了下⾯两种情况的操作，在此做⼀详细记录：(1)第⼀种情况：gerrit上还没有创建项⽬《gerrit上的项⽬最好是从gitlab上git clone --bare过来，并且项⽬不要为空》思路：先在gitlab上创建分⽀（上⾯截图），然后在linux服务器（这⾥选择gerrit本机）git clone下载gitlab⾥的项⽬（如上⾯的apptest）最后将整个项⽬发布到gerrit上《注意，上⾯在新分⽀下添加的.gitreview⽂件⼀定要有，不然就不能使⽤git review命令提交代码审核了，具体上⾯参考的另⼀篇博客中有说明》在gerrit的⼀个普通⽤户如wangshibo下操作：如果修改apptest项⽬的⾮master分⽀下的代码，如上⾯的dev分⽀⽤ gerrit⽤户在 Gerrit 上创建 test-project1 项⽬要知道 review 是在 gerrit 上，⽽ gerrit 上现在是没有项⽬的，想让 gitlab 上的项⽬能在 gerrit 上 review 的话，必须在 gerrit 上创建相同的项⽬，并有相同的仓库⽂件.⽤ gerrit⽤户在 Gerrit 上创建 apptest 项⽬[gerrit@115]$ ssh-gerrit gerrit create-project apptest ＃这时候gerrit上其实已经有apptest项⽬了<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<ssh-gerrit是别名[gerrit@115r ~]$ cat ~/.bashrc# .bashrc# Source global definitionsif [ -f /etc/bashrc ]; then. /etc/bashrcfialias ssh-gerrit='ssh -p 29418 -i ~/.ssh/id_rsa 103.10.86.30 -l gerrit'# User specific aliases and functions<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<虽然上⾯创建了apptest项⽬，并且gerrit界⾯⾥已经有这个项⽬，但是个空⽬录我们需要将Gitlab上的apptest项⽬发布到gerrit上在此需要⽤到git clone –bare 命令[gerrit@115]$ cd /home/gerrit/gerrit_site/git/ #即登陆到gerrit安装⽬录的git下[gerrit@115 git]$ rm -fr apptest.git[gerrit@115 git]$ git clone --bare git@103.10.86.30:test/apptest.git[gerrit@115 git]$ lsAll-Projects.git All-Users.git apptest.git[gerrit@115 git]$ cd apptest.git/[gerrit@115 git]$ ls ＃即test-project1⼯程和gerrit⾥默认的All-Projects.git⼯程结构是⼀样的了branches config description HEAD hooks info objects packed-refs refs登陆gerrit界⾯，发现apptest⼯程已经创建了。

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、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、申请账号通过邮件向***************发邮件申请，打开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 选项,请确保正确方式进行项目库下载gitclonessh://*******************.31.10:29418/Test3、提交注意事项每一个新clone的库第一次提交都需要执行以下步骤(下载服务端钩子到本地库，以便提交评审形成chang-id)*************************************.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。

gerrit管理下的git代码提交小技巧

gerrit管理下的git代码提交⼩技巧1、提交代码git checkout targetbranch 切换⾄⽬标分⽀git pull origin targetbranch 拉取⽬标分⽀最新内容git add 修改⽂件git commit -m “修改内容:xxxxx”git push origin HEAD:refs/for/targetbranch2、修改代码后发现所在分⽀不是⽬标分⽀怎么办？修改代码的分⽀是A，⽽需要提交的分⽀是B, 有两种办法：⽅法⼀：1> 新建⼀分⽀C，保留现在的分⽀修改内容；2>git branch C3> 切换⾄⽬标分⽀B，拉取C分⽀的内容⾄分⽀B；git checkout Bgit fetch origin C4> 检查修改⽂件变化和内容是否原来修改的⼀致git statusgit diff ⽂件5> 按照提交代码环节操作即可；⽅法⼆：1> 将A分⽀上修改的内容放到回收站⼯作树，这个相当于是⼀个栈，可以进⾏压⼊弹出，⽐栈更⾼级的是可以根据索引进⾏弹出；git stash2> 切换⾄B分⽀git checkout B3> 从回收站恢复修改数据⾄B分⽀git stashgit stash list 查看回收站中存在的⽂件；git stash show 查看回收站中相对本地⽂件的变化，与git diff类似；git stash pop 恢复回收站最顶层数据⾄本地；4> 按照提交代码环节操作即可3、修改提交后发现提交的内容存在问题怎么办？如果提交后的代码还没有merge到对应分⽀，可按照如下⽅法:1> 切换⾄原来修改提交所在分⽀git checkout targetbranch2> 继续修改内容3> git add 修改⽂件4> git commit --amend5> git push origin HEAD:refs/for/targetbranch如果提交后的代码已经merge，按照正常修改提交代码流程即可；4、A B C三个⼈同⼀时间段内提交代码，此时B提交的代码已经merge, ⽽C发现他提交的代码与A有冲突conflict，怎么办？1> 切换⾄原来修改提交所在分⽀，切换⾄⾃⼰修改前的⼀次提交commit-idgit checkout targetbranchgit log | lessgit reset commit-id2> 拉取合并代码更新git pull origin HEAD:refs/for/targetbranch3> git add 修改⽂件解决冲突，主要是⽂件中包含HEAD的地⽅，其中HEAD XXX ====中的XXX是本地旧内容;4> git commit -m “修改内容：xxx”5> git push origin HEAD:refs/for/targetbranch5、拉取代码失败1> 确认拉取⽅式是否为带hook的sshgit clone ssh://chenxiaoyuan@10.75.9.60:29418/CGDL-F25/src/mate-related && scp -p -P 29418chenxiaoyuan@10.75.9.60:hooks/commit-msg mate-related/.git/hooks/2> 确认⾃⼰的ssh公钥是否重新⽣成过，或者没有添加⾄gerrit帐户的认证信息中。

gerrit使用git review提交

gerrit使用git review提交摘要：一、Gerrit简介二、Gerrit与Git的关联三、Git Review提交的使用四、总结正文：Gerrit是一个代码审查工具，它基于Web且与Git紧密结合，可以帮助开发团队更高效地进行代码审查和协作。

在Gerrit中，用户可以使用Git进行代码提交和版本控制，并通过Gerrit进行代码审查。

Gerrit与Git之间的关联非常紧密，因为Gerrit是基于Git实现的。

在Gerrit中，代码仓库分为两种：Gerrit项目和Git仓库。

Gerrit项目是一个特殊的Git仓库，它包含了Gerrit服务器上的所有代码审查信息。

当你向Gerrit 项目提交代码时，Gerrit会将你的提交信息与代码仓库关联起来，并将其提交到Gerrit服务器进行代码审查。

在Gerrit中，有两种提交方式：直接提交和使用Git Review提交。

直接提交是指直接使用Git命令行工具进行提交，这种方式适用于简单的代码提交。

而Git Review提交则是通过Gerrit Web界面进行的，它提供了更丰富的功能，如代码审查、合并等。

今天我们将重点介绍Gerrit中的Git Review提交。

使用Git Review提交时，首先需要在Gerrit Web界面上创建一个新提交。

在创建提交时，需要填写提交信息，如提交者、提交时间、提交注释等。

填写完毕后，点击“提交”按钮，Gerrit会将你的提交信息与代码仓库关联起来，并将其提交到Gerrit服务器进行代码审查。

在代码审查过程中，团队成员可以在Gerrit Web界面上查看代码、提交注释以及进行评论。

审查完成后，如果代码通过了审查，团队成员可以点击“合并”按钮，将代码合并到主分支。

如果代码未通过审查，团队成员可以在Gerrit Web界面上提出修改意见，开发人员根据意见进行修改并重新提交代码。

总之，Gerrit作为一款强大的代码审查工具，与Git紧密结合，提供了便捷的代码提交和管理功能。

gerrit使用git review提交

gerrit使用git review提交（原创版）目录1.Gerrit 简介2.Git Review 的使用3.Gerrit 使用 Git Review 提交的步骤4.注意事项正文1.Gerrit 简介Gerrit 是一个基于 Web 的代码审查工具，它可以帮助团队更方便地进行代码审查。

Gerrit 基于 Git，因此可以充分利用 Git 的功能，例如分支管理和合并请求。

在 Gerrit 中，所有的代码提交都需要经过审查，然后才能合并到主分支。

2.Git Review 的使用Git Review 是一个命令行工具，它可以帮助用户在 Gerrit 中创建审查。

使用 Git Review，用户可以提交一个包含更改的 Git 仓库快照，并附带一份描述性的注释。

然后，Gerrit 会自动将这个提交转换为一个审查，并通知其他团队成员进行审查。

3.Gerrit 使用 Git Review 提交的步骤在 Gerrit 中使用 Git Review 提交的步骤如下：（1）首先，确保已经安装了 Git Review 工具。

如果尚未安装，可以使用以下命令进行安装：```git review install```（2）然后，使用以下命令创建一个新的审查：```git review create <gerrit_url> <branch_name> <commit_hash> -m "提交描述"```其中，`<gerrit_url>`是 Gerrit 服务器的 URL，`<branch_name>`是要提交的 Git 分支的名称，`<commit_hash>`是 Git 提交的哈希值，`-m`选项后面的内容是提交描述。

（3）在创建审查后，Gerrit 会自动将审查转换为一个合并请求。

此时，需要登录到 Gerrit，然后导航到相应的合并请求页面。

Git权威指南-第5篇-第32章-Gerrit

第32章Gerrit 代码审核服务器谷歌 Android 开源项目在 Git 的使用上有两个重要的创新，一个是为多版本库协同而引入的repo，这在前面第25章已经详细讨论过。

另外一个重要的创新就是 Gerrit ——代码审核服务器。

Gerrit 为 Git 引入的代码审核是强制性的，也就是说除非特别的授权设置，向 Git 版本库的推送必须要经过 Gerrit 服务器，修订必须经过代码审核的一套工作流之后，才可能经批准并纳入正式代码库中。

首先贡献者的代码通过 git 命令（或 repo 封装）推送到 Gerrit 管理下的 Git 版本库，推送的提交转化为一个一个的代码审核任务，审核任务可以通过refs/changes/下的引用访问到。

代码审核者可以通过 Web 界面查看审核任务、代码变更，通过 Web 界面做出通过代码审核或打回等决定。

测试者也可以通过refs/changes/之下的引用获取修订然后对其进行测试，如果测试通过就可以将该评审任务设置为校验通过（verified）。

最后经过了审核和校验的修订可以通过Gerrit 界面中的提交动作合并到版本库对应的分支中。

Android 项目网站上有一个代码贡献流程图1，详细地介绍了 Gerrit 代码审核服务器的工作流程。

翻译后的工作流程图见图32-1。

1 /source/life-of-a-patch.html图32-1：Gerrit 代码审核工作流32.1Gerrit 的实现原理Gerrit 更准确地说应该称为 Gerrit2。

因为 Android 项目最早使用的评审服务器 Gerrit 不是今天这个样子的。

最早版本的 Gerrit 是用 Python 开发运行于 Google App Engine 上的，从 Python 之父 Guido van Rossum 开发的 Rietveld 分支而来。

在这里要讨论的 Gerrit 实为 Gerrit2，是用Java 语言实现的1。

Gerrit日常维护记录

Gerrit⽇常维护记录Gerrit代码审核⼯具是个好东西，尤其是在和Gitlab和Jenkins对接后，在代码控制⽅⾯有着⽆与伦⽐的优势。

在公司线上部署了⼀套Gerrit系统，在⽇常运维中，使⽤了很多gerrit命令，在此收集下：⼀、创建和销毁（1）分⽀列表：$: git branch* masterprepubproduct（2）创建分⽀：$: git branch prepub（3）切换已有分⽀：$: git checkout prepubSwitched to branch 'prepub'（4）创建并切换分⽀：$: git checkout -b issue1234Switched to branch 'issue1234'（5）删除分⽀：$: git branch -d issue1234Deleted branch issue1234 (was b904c07).⼆、合并和冲突（1）合并前要先切回要并⼊的分⽀。

以下表⽰issue1234分⽀合并⼊master分⽀$: git checkout master$: git merge issue1234Merge made by recursive.README | 1 +1 files changed, 1 insertions(+), 0 deletions(-)冲突的时候，git会报出哪些⽂件冲突，这时候需要⼿动解决完冲突⽅可提交。

$: git merge issue1234Auto-merging index.htmlCONFLICT (content): Merge conflict in index.htmlAutomatic merge failed; fix conflicts and then commit the result.通过git status查看冲突⽂件。

$: git statusindex.html: needs merge# On branch master# Changed but not updated:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)## unmerged: index.html#打开index.html，git会在冲突位置做上标⽰。

gerrit常用命令笔记

gerrit常⽤命令笔记repo使⽤笔记：rsync -avr .repo [username]@yourServerIP:/home/ 同步.repo配置到⽬标服务器绝对路径下repo sync -l 同步完上⾯.repo配置后使⽤此命令同步代码repo list -nr sboot 列举sboot仓库路径repo list dtv/fusion-bsp2/mstar/mboot/sboot 查仓库映射关系git使⽤笔记：⼀、新服务器git环境配置git config --global "[username]" 配置⽤户名git config --global user.email "[emailAddress]" 配置邮箱ssh-keygen ⽣成ssh-key，拷贝~/.ssh/id_rsa.pub内容到gerrit上注册⼆、提交修改部分1、git diff [filename] 显⽰本地与远程git库中⽂件差异-b PATH，忽略空格，显⽰差异2、git stash，保存⼯作区修改的现场，以得到⼲净的代码-- pop，恢复保存的⼯作区修改，继续未完成的⼯作-- list，查看stash列表-- clear，清除所有的stash history3、git status，查看⼯作⽬录状态，包含当前分⽀信息及修改信息等。

git add xxx或git add -i，添加到commit暂存区（如果add之后再次修改相同⽂件，需要再次add，否则第⼆次修改的内容不会被放到暂存区）4、git reset HEAD <file>...，撤出暂存区（与add相反）5、git commit -m "Comment Something"或者git commit -F xxx.log，添加版本注释，并提交暂存区到本地版本库6、git commit --amend 在当前commit上修改提交内容7、git reset --soft HEAD^，回滚最近⼀次commit，重新修改后，可以再次commit。

gerrit 使用方法

gerrit 使用方法Gerrit是一款非常流行的代码审查工具，能够帮助团队更好地管理代码质量和版本控制。

本文将介绍如何使用Gerrit来进行代码审查。

步骤一：安装Gerrit首先，需要安装Gerrit并完成配置。

Gerrit的安装可以分为两个部分：安装Java运行环境和安装Gerrit程序。

可以通过官方网站的帮助文档获得详细的安装指导。

步骤二：创建Gerrit用户一旦Gerrit安装完毕，需要创建一个Gerrit用户。

这个用户是Gerrit管理界面的主账户，用于管理Gerrit的各项设置和配置。

步骤三：项目创建和导入在Gerrit里可以进行代码审查的前提是要有代码仓库，因此需要创建或者导入一个项目。

通常情况下，项目的仓库是从Git或其他版本控制系统导入的。

Gerrit允许根据项目名称、代码仓库 URL 等信息创建或者导入一个或多个项目，具体可以参照官方文档。

步骤四：注册用户在进行代码审查之前，还需要注册一个Gerrit用户账户。

可以在Gerrit管理页面上进行用户的注册操作，填写用户昵称、用户名、电子邮件等必填信息，并按照指引完成注册。

注册完成之后，Gerrit会自动将该用户与 Git 账户相关联起来。

步骤五：创建分支接下来，需要为项目创建一个分支以便进行代码审查。

可以在Gerrit 管理页面上创建一个分支，并将其与 Git 仓库同步。

步骤六：提交变更当分支创建好后，就可以提交变更（如新增文件、修改文件内容等）了。

有两种方式可以进行提交：一是通过 Git 命令行操作，将变更导入到 Gerrit；二是在 Gerrit 管理页面上进行变更内容的发布。

步骤七：开启审查当变更被提交时，Gerrit就会自动开启一次代码审查流程。

此时，需要审核人员对变更内容进行审查，并发布审查意见。

Gerrit会自动将审查意见发送给提交人，以便进行确认。

步骤八：发布变更如果审核人员对变更内容进行了批准，那么提交人就可以发布该变更了。

gerrit 的submit type选项

gerrit 的submit type选项Gerrit是一个基于Git的代码审查工具，它通过提供一个Web界面来帮助开发人员进行代码审查和合并。

在提交代码时，Gerrit提供了一系列Submit Type选项，用于指定代码合并的方式。

下面将详细介绍Gerrit的Submit Type选项。

1.快速合并（Fast forward）快速合并是最简单的合并方式。

当两个分支没有冲突时，Gerrit 会执行一个“快进合并”，即将新分支的头指针直接移动到目标分支的头部，这样就完成了一个快速合并。

2.合并快照（Merge commit）合并快照是另一种合并方式。

如果两个分支有冲突，或者开发人员选择手动进行合并，Gerrit会创建一个合并快照。

这个合并快照是一个新的提交，它将两个分支的更改合并在一起，并创建一个新的提交。

3.检查合并（Cherry pick）检查合并允许开发人员选择一个或多个特定的提交，只将这些提交合并到目标分支中。

这个选项在需要选择部分提交进行合并时非常有用。

4.合并Squash（Squash）合并Squash是一种将多个提交合并为一个提交的方式。

当开发人员在自己的分支上进行多次提交，但希望将这些提交合并为一个更具可读性的提交时，可以使用这个选项。

5.重新合并（Rebase）重新合并是将一个分支的更改应用到另一个分支上的一种方式。

它将新分支的更改放在目标分支的最新提交之后，并创建一个新的提交来合并这些更改。

重新合并可以帮助保持提交历史的整洁。

6.依赖合并（Dependency）依赖合并是一种将多个相关提交合并为一个提交的方式。

当有多个提交需要按顺序进行合并时，可以使用这个选项。

它确保了相关提交的正确合并顺序。

7.链式依赖合并（Chained dependency）链式依赖合并是在依赖合并的基础上增加了一种依赖提交的合并方式。

当某个提交依赖于之前的多个提交时，链式依赖合并可以按照正确的顺序将这些提交合并为一个提交。

Gerrit-一些基本用法

Gerrit-⼀些基本⽤法1 - 主配置⽂件主配置⽂件位于$GERRIT_SITE/etc/gerrit.config⽬录[gerrit@mt101 ~]$ cat gerrit_testsite/etc/gerrit.config[gerrit]basePath = gitcanonicalWebUrl = http://192.168.16.101:8083/serverId = 0b911b9e-195a-46b0-a5cd-b407b776b344[container]javaOptions = "-Dflogger.backend_factory=mon.flogger.backend.log4j.Log4jBackendFactory#getInstance"javaOptions = "-Dflogger.logging_context=com.google.gerrit.server.logging.LoggingContext#getInstance"user = rootjavaHome = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-2.b14.el7.x86_64/jre[index]type = lucene[auth]type = HTTP[receive]enableSignedPush = false[sendemail]smtpServer = localhost[sshd]listenAddress = *:29418[httpd]listenUrl = http://192.168.16.101:8083/[cache]directory = cache[gerrit@mt101 ~]$2 - Gerrit的⽤户和群组Gerrit是基于群组来进⾏权限控制的，不同的群组具有不同的权限。

【gerrit】gitpushoriginHEAD：refsforxxx的意思

【gerrit】gitpushoriginHEAD：refsforxxx的意思1.git push <remote 名字> <本地分⽀的名字> : <远程库的名字>git push origin HEAD:refs/for/xxxgit push 推送origin : 是远程的库的名字xxx:就是填你的分⽀名HEAD: 是⼀个特别的指针，它是⼀个指向你正在⼯作的本地分⽀的指针，可以把它当做本地分⽀的别名，git这样就可以知道你⼯作在哪个分⽀refs/for :意义在于我们提交代码到服务器之后是需要经过code review 之后才能进⾏merge的refs/heads 不需要2. 这个不是git的规则，⽽是gerrit的规则，Branches, remote-tracking branches, and tags等等都是对commite的引⽤（reference）,引⽤都以 “refs/……”表⽰. ⽐如remote branch: origin/git_int(=refs/remotes/origin/git_int)， local tag: v2.0(=refs/tags/v2.0)， local branch: git_int(=refs/heads/git_int)…简单点说，就是refs/for/mybranch需要经过code review之后才可以提交；refs/heads/mybranch不需要code review。

下⾯⼀段是对“refs/for”更详细的描述：The documentation for Gerrit explains that you push to the "magical refs/for/'branch' ref using any Git client tool".This image is taken from the Intro to Gerrit. When you push to Gerrit, you do git push gerrit HEAD:refs/for/<BRANCH>. This pushes your changes to the staging area (in the diagram, "Pending Changes"). Gerrit doesn't actually have a branch called <BRANCH>; it lies to the git client.Internally, Gerrit has it's own implementation for the Git and SSH stacks. This allows it to provide the "magical" refs/for/<BRANCH> refs.When a push request is received to create a ref in one of these namespaces Gerrit performs its own logic to update the database, and then lies to the client about the result of the operation. A successful result causes the client to believe that Gerrit has created the ref, but in reality Gerrit hasn’t created the ref at all.After a successful patch (i.e, the patch has been pushed to Gerrit, [putting it into the "Pending Changes" staging area], reviewed, and the review has passed), Gerrit pushes the change from the "Pending Changes" into the "Authoritative Repository", calculating which branch to push it into based on the magic it did when you pushed to refs/for/<BRANCH>. This way, successfully reviewed patches can be pulled directly from the correct branches of the Authoritative Repository.。