背景

公司使用Gerrit作为代码托管平台。
Gerrit除了设置项目权限外，还提供了很好的code review功能。
下面分别简单介绍普通Git用法和code review用法

普通Git使用方法：

如上图所示：

Git仓库主要分为：本地仓库（各位clone到本机）和远端仓库（scm负责维护的，搭建在一台服务器上面）；

绝大多数的命令都不需要和远端的git仓库打交道，本地执行即可；

1
2
3
4

git clone :克隆一个远端git仓库到本地
git fetch：获取远端git仓库变化到本地仓库，并不会更改当前工作区文件
git pull：这个命令相当于：先执行git fetch 然后执行git merge变化到当前工作区
git push：将本地仓库的变化推送到远端git服务器

Code Review使用方法：

如上图所示：
使用Gerrit进行code review一言蔽之就是Gerrit加了个中间层；
本地仓库的变更执行git push提交到Gerrit；code reviewer可以在gerrit上面对本次提交进行review并给出评价；

管理员在review评估ok（至少有一个+2）后，在gerrit上面点击submit，会把本次变更推送到远端仓库。

PS:+1 +2 -1 -2 0不是数字意义！！！（两个reviewer都给了+1评论并不代表已经+2了）

原理解析：

为了实现上面所说的功能，gerrit引入了change_id和for空间；

我们执行git push到for空间；
如果大家的本地git config没有做过配置，那么咱们执行git push的完整命令是：
git push origin HEAD:refs/heads/master
推送当前本地最新代码到远端（origin）master分支

使用code review的话执行git push完整命令是：
git push origin HEAD:refs/for/master
推送当前本地最新代码到for空间的master分支供gerrit识别

PS：以上写的都是git原始命令供大家更好的理解，实际使用中可以简写！！！

Gerrit根据change-Id识别你的patch；

我们需要引入commit-msg钩子文件到本地代码库:
（这个是gerrit原生提供的通过scp命令实现）
在本地代码库下运行（将weilong.wang改成自己的用户名），执行一次即可
gitdir=$(git rev-parse –git-dir); scp -p -P 29418 weilong.wang@Gerrit_Server_Ip:hooks/commit-msg ${gitdir}/hooks/

commit-msg钩子的作用和使用：
1.Dev正常本地修改代码，git add，git commit 会自动在message后面增加算出一个唯一的change-id
例如： Change-Id: I45088f6b73bf53b62b2ee3b09c005952e9838548
2.如果本次patch提交到gerrit后，review不通过：本地修改代码， git add， git commit –amend
（更新新的修改到当前commit；同时可以修改commit message；不要对message的最后一行change-id做修改！！！）
接着push到gerrit：因为change-id并没有改变，所以还是同一个地方，patch set增长1

PS：建议合并最新版本代码到本地：使用git pull –rebase
如果使用git pull： merge点不自动产生change-id！！！

喜闻乐见简化配置：

根据上面的解释大家应该发现想使用gerrit进行code review还得手工做些事情：

1. git clone远端代码库到本地
2. 从远端服务器下载commit-msg钩子到本地仓库.git/hooks/目录
3. 每次都要本地git commit后执行git push origin HEAD:refs/for/master
4. 去gerrit上面添加code reviewers
   这并不是我想要的生活。。。

一劳永逸方法：

1. git clone远端代码库到本地
2. 从远端服务器下载commit-msg钩子到本地仓库.git/hooks/目录
3. 修改本地代码库config vi .git/config增加下面内容
   [remote “review_master”]
   url = 代码库地址
   push = HEAD:refs/for/master%r=weilong.wang@memblaze.com,r=dev1@memblaze.com
4. 本地git commit后执行git push review_master即可
   会自动提交到refs/for/master并增加weilong和dev1作为code reviewers;

PS： remote “review_master” 这个可以换成你喜欢的其他字符串；假如改成remote “haha” 那么最终push的时候执行 git push haha
PS： pushurl这个请自行替换成各位执行git clone的地址
PS： 自动添加code reviewers请自行替换成各位项目的同事

Comment and share

软件版本：

1

git version 2.10.1

Git克隆单个分支：

1
2
3
4
5
6
7
8
9

$ git clone 地址 —branch br1 —single-branch dir
        只能看到单独的br1，不能checkout到其他分支。空间占用比较小，适合长期分支开发。
原理：
$ git remote -v
        remote.origin.fetch=+refs/heads/br1:refs/remotes/origin/br1
恢复完整代码库：
$ git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
    然后执行
    $ git pull

Git对.gitignore文件处理：

1
2
3
4
5
6

已经增加到.gitignore文件里面的目录or文件会被git忽略。
如果本次需要修改一个忽略文件：
$ git status --ignored
            --ignored   -- show ignored files as well
$ git add -f
            --force   -f   -- allow adding otherwise ignored files

Git commit相关：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 空提交,只在特殊情况下使用（产生一个新的commit点）
$ git commit
    On branch master
    Your branch is up-to-date with 'origin/master'.
    nothing to commit, working tree clean
# 解决方法
$ git commit -m "empty commit" --allow-empty


# 不带message提交（慎用,message很重要）
$ git commit
    Aborting commit due to empty commit message.
# 解决方法
$ git commit --allow-empty-message


把暂存区的变更合并到最新的版本里面，不会产生新的版本(同时可以更新log message)；
$ git commit --amend
PS：已经进远端代码库的版本不允许使用--amend进行修改!!!

Git merge相关：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

conflict处理：
# 使用自己/他人的文件替换冲突文件
$ git checkout --ours conflict.file
$ git checkout --theirs conflict.file
# 增加冲突文件到版本库
$ git add conflict.file
$ git commit


查看merge commit点已经解决的冲突文件：
$ git log --cc
        --cc    -- combined diff format for merge commits


分支直接合并建议使用：git merge
同一分支dev合并 or Temp分支合并建议使用：git rebase 或者 git cherry-pick
    PS：以上两种都可以合并代码workspace最终文件一样，但是对git来说有不同：merge是环形，rebase和cherry-pick是直线
    PS：需要注意的是rebase会是自己和他人角色发生反转，解决conflict file的时候需要留心。

Git rm相关：

1
2
3
4
5

$ git rm weilong.txt
删除workspace和index里面的weilong.txt文件

$ git rm --cached weilong.txt
删除index里面的weilong.txt文件，workspace里面的文件保留

Git log相关：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

$ git log -5
查看最新的5次版本

$ git log --author=weilong.wang
查看weilong.wang提交的版本

$ git log --oneline
一行显示一个版本信息（简化显示版本信息）

$ git log -p
显示每个版本的具体修改

$ git log --numstat
显示每个版本 修改文件的行数（5       1       weilong.txt    这个文件本次增加了5行同时也删除了1行）

$ git log --since="1 month ago"
显示最近一个月的日志
$ git log --after="2016-07-01"
显示7月1号至今的日志
$ git log --before="2 days"
显示2天之前的日志
$ git log --until="2016-07-10T14:30"
显示7月10号14：30之前的日志


$ git log --graph
图状显示版本 （正常提交时线形的，merge是环形的）

可用于判断分支是否合并：
$ git log br1 ^master
显示只在分支br1不在master上的commit点
$ git log master ^br1
显示只在分支master不在br1分支上的commit点

Comment and share

背景：

公司目前使用Gerrit作为代码库托管和Code review平台。 使用Jenkins作为自动化构建和持续集成平台。

流程设计：

1. Dev本地开发，然后上传patch到gerrit：

• 同时触发Jenkins CR_Job来做build
• 增加Code reviewers来做review

2. 再上述都成功的基础上，reviewer点击+2：

• 同时触发Jenkins Submit_Job来做build和test：
  • 如果成功，自动合并本次patch到代码库
  • 如果失败，返回-1

3. Nightly test Job：

• 每晚20:00触发，获取当前最新的代码进行build和test

测试分级：

• CR_Job:
  • 获取触发patch的代码，合并最新分支代码，进行build
  • 快速反馈，主要检查patch合并是否有冲突和build是否能跑通

• Submit_Job：
  • 获取触发patch的代码，合并最新的分支代码，进行build和测试
  • 根据每天代码提交次数来确定时间和test cases

• Nightly_Job：
  • 获取当前最新代码进行build和test
  • 一般跑12h，第二天早上出测试报告邮件

软件环境：

• Jenkins插件：

搭建步骤：

1. 安装配置Jenkins Gerrit Trigger插件：官方wiki
   
2. 安装Jenkins Multijob plugin：官方wiki
   
3. 配置CR_Job:
   
4. 配置Submit_job:
   
5. 配置Nightly_Job:
   

PS

1. 以上内容都是基于公司研发现状定制的，建议各位根据自己的情况进行定制。
2. 因为历史遗留原因，当前使用的版本比较旧。 例如如果升级到jenkins2.x版本的话pipeline就不需要借助插件来实现了。

Comment and share

软件版本：

1

jenkins 1.567

• build-user-vars-plugin
  https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin
  用途：获取构建的执行人信息 需要在job配置中勾选Set jenkins user build variables

• gerrit-trigger
  https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
  用途：打通gerit和jenkins 主要用于：gerrit事件触发jenkins job，jenkins job执行结果反写回gerrit

• thinBackup
  https://wiki.jenkins-ci.org/display/JENKINS/thinBackup
  用途：备份jenkins配置和job配置

• saferestart
  https://wiki.jenkins-ci.org/display/JENKINS/SafeRestart+Plugin
  用途：提供一个按钮来安全重启jenkins 点击后，如果有job正在执行那么等job执行完毕后会重启jenkins，点击后再加进来的job会等待重启完成后执行。

• jobConfigHistory
  https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory+Plugin
  用途：记录每次job配置变更，支持查找历史版本和回滚

• rebuild
  https://wiki.jenkins-ci.org/display/JENKINS/Rebuild+Plugin
  用途：增加rebuild按钮用来使用相同的参数再次执行构建 gerrit触发的job 要使用 Retrigger 而不是rebuild

• jenkins-multijob-plugin
  https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin
  用途：多个job组成工作流 优点：比其它组job流的插件多了最终收集结果功能，而且界面配置简单，功能强大

• multiple-scms
  https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin
  用途：job支持多个git工程 并且可以配置下载代码到指定目录

• Copy Artifact Plugin
  https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin
  用途：拷贝其它job的指定产出物

Comment and share