背景：

为了更好的支持产品研发过程，我们需要设计符合公司研发的分支策略。
无论多复杂或者简单的策略都可以归类为以下两种：

1.主干开发，分支发布
2.分支开发，主干发布

PS：我们约定：

主干（master/git trunk/svn）
分支（branch）
标签（tag）
如果从版本控制工具实现上来看：
svn： trunk、branch、tag 没有差别
git： master、branch、轻量级tag 没有差别
为了更好的区分和管理，人为的从逻辑上进行区分
tag的作用：里程碑记录，方便回溯（发布回滚等）

主干开发，分支发布：

• 优点：
  1. 较少的分支存在，大家专注在主干开发
• 适用于：
  1. 敏捷开发模式，每个迭代都很快
  2. 维护型项目，较少需求变更，基本没有并行开发的需要
  3. 个人项目
• 常用方式：
  1. 所有dev在主干上面进行开发
  2. 需要发布的时候从指定版本拉出发布分支，进行测试
     • 如果成功：那么打出tag，进行发布
     • 如果不成功：那么继续在发布分支上面进行修改，然后测试；
       测试成功后，打tag，合并发布分支修改到主干；

分支开发，主干发布：

• 优点：
  1. 对并行开发支持很好
• 适用于：
  1. 并行开发很频繁的项目
• 常用方式：
  1. 根据项目发布排期拉出并行开发分支
  2. 不同or相同的dev分别在分支上面进行开发
  3. 测试通过后，打tag进行发布，合并分支修改到主干
  4. 后发布的分支需要合并最新的主干代码
• 注意点：
  1. 所有分支都从主干拉出；
  2. 发布时候要检查 tag是否包含最新的主干代码；
  3. 后发布的分支在合并最新主干代码后，注意测试范围扩大（除了测试本分支功能外，合并过来的功能也需要覆盖到！！！）

PS：

本文只是简单介绍下基础的分支策略，各位需根据自身团队、业务来综合定制适合的分支策略。

Comment and share

背景

公司使用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