├── .gitreview ├── Hell.java ├── README.md ├── build.sh └── hello.py /.gitreview: -------------------------------------------------------------------------------- 1 | [gerrit] 2 | host=review.bitcomm.cn 3 | port=29418 4 | project=testing.git 5 | defaultbranch=master 6 | -------------------------------------------------------------------------------- /Hell.java: -------------------------------------------------------------------------------- 1 | public class Hello{ 2 | 3 | 4 | } 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Gerrit和git的流程 2 | 3 | ## 资源 4 | 5 | * 公司git服务器 6 | 7 | 8 | 9 | 注意将testing换成对应的项目 10 | 11 | * 公司gerrit评审系统 12 | 13 | 14 | 15 | * jenkins CI服务器 16 | 17 | 18 | 19 | * github上的testing项目, 从gerrit自动同步到github 20 | 21 | 22 | 23 | ## 参考资料： 24 | 25 | ### 有关git的参考资料 26 | 27 | * pro git中文版, 最好的git书籍 28 | 29 | 30 | 31 | * 图解git 32 | 33 | 34 | 35 | * git交互式学习 36 | 37 | 38 | 39 | * Git分支管理策略 40 | 41 | 42 | 43 | * type3的关于git和Gerrit资料 44 | 45 | 46 | 47 | * egit 和 gerrit的实践应用 48 | 49 | 50 | 51 | ### 有关gerrit 的参考资料 52 | 53 | * 54 | * 55 | * 56 | * 57 | * 58 | * 59 | * 60 | * 61 | * 62 | * 63 | * 64 | 65 | ## 注册帐号 66 | 67 | 在注册用户，采用的是openid统一认证，直接使用公司的google邮箱就可以了。 68 | 69 | 注册的时候，注意: 70 | 71 | * 设置自己的用户名，必须为英文或者数字，这个后面授权需要用到，比如我选择的是 refactor 72 | * 导入自己的公钥，这个在 git 进行 review操作的时候，授权需要用到 73 | 74 | 注册完了以后，可以看到 testing 项目，可以进行练习和测试。其余的项目，联系项目经理进行授权，将下面的信息发送给项目经理： 75 | 76 | 注册的邮箱、ssh公钥和对应的项目 77 | 78 | 79 | ## 工具安装 80 | 81 | ### Windows 82 | 83 | * 安装git 工具 84 | 85 | 由于目前git的命令行功能和稳定性比图形界面的egit等强，大家在代码递交时，还是使用Windows或者Linux的命令行，windows下可以采用： 86 | 87 | windows下的命令行工具： 88 | 89 | 90 | 91 | windows下的图形工具： 92 | 93 | 94 | 95 | 下载安装windows版本的python，一般可以选用2.7.3 96 | 97 | 98 | 99 | 下载安装windows版本的setuptools 100 | 101 | 102 | 103 | 下载、解压、安装 pip 软件 104 | 105 | 106 | 107 | 进入解压以后的目录，然后执行安装： 108 | 109 | python setup.py install 110 | 111 | 使用pip安装 fabric 和 git-review 112 | 113 | pip install fabric git-review 114 | 115 | ### Ubuntu 116 | 117 | sudo aptitude install python-pip 118 | sudo pip install fabric git-review 119 | 120 | ### CentOS 121 | 122 | sudo yum -y install python-setuptools python-devel python-pip 123 | sudo pip-python install fabric git-review 124 | 125 | ## 导出项目，初始设置 126 | 127 | 配置递交代码人信息： 128 | 129 | git config --global user.name "Peng Yong" 130 | git config --global user.email ppyy@pubyun.com 131 | 132 | 从git取出代码： 133 | 134 | git clone ssh://git@git.bitcomm.cn:2203/testing.git 135 | 136 | 注意选用自己需要的项目名称替代 testing 137 | 138 | 设置git review 系统, 第一次需要回答一个用户名，就是你在review系统的用户名 139 | 140 | git review -s 141 | 142 | 如果没有安装 git review 软件包，则手工设置： 143 | 144 | git remote add gerrit ssh://refactor@review.bitcomm.cn:29418/testing.git 145 | scp -P 29418 refactor@review.bitcomm.cn:hooks/commit-msg .git/hooks/ 146 | 147 | 注意: 148 | 149 | * 选用自己需要的项目名称替代 testing 150 | * 使用自己的用户名替代 refactor 151 | 152 | ## 日常开发流程 153 | 154 | 当需要修改一个bug，或者开发新功能时, 需要分几部： 155 | 156 | 获取最新的代码, 防止和他人冲突 157 | 158 | git fetch origin 159 | 160 | 每一个开发（bug，feature），都创建一个独立的开发分支，不要在 master上做，一般一个单元开发创建一个分支，互相不混淆。否则如果评审不通过，重新修改会麻烦： 161 | 162 | git checkout -b dev/username/typefix 163 | git checkout -b dev/username/login_module 164 | 165 | 修改代码，然后检查代码： 166 | 167 | git status 168 | git diff 169 | 170 | 如果要放弃commit，使用 ： 171 | 172 | git reset --soft HEAD^ 173 | 174 | 本地递交代码: 175 | 176 | git commit –a 177 | 178 | 注意，看一下这些文件是否都要递交，写好简要、清晰的递交日志。 179 | 180 | 上传代码，等待评审： 181 | 182 | git review 183 | 184 | 如果没有安装 git review 软件，则手工上传，等待评审： 185 | 186 | git push gerrit HEAD:refs/for/master 187 | 188 | 如果代码审查通过，合并完成以后，可以删除这个分支： 189 | 190 | git checkout master 191 | git branch -d dev/username/typefix 192 | 193 | ## 如果评审不通过，需要再次修改代码，则继续在原来的分支修改代码 194 | 195 | 切换到原来的开发分支： 196 | 197 | git checkout bug/typefix 198 | 199 | 修改代码… 200 | 201 | 然后递交（注意，一定使用 amend选项，这样可以继续递交在原来的review单号上） 202 | 203 | git commit -a --amend 204 | 205 | 上传代码等待审批 206 | 207 | git review 208 | 209 | 如果没有安装 git review 软件，则手工上传，等待评审： 210 | 211 | git push gerrit HEAD:refs/for/master 212 | 213 | 如果代码审查通过，合并完成以后，可以删除这个分支： 214 | 215 | git checkout master 216 | git branch -d bug/typefix 217 | 218 | ## 审批通过以后，gerrit提示有冲突怎么办 219 | 220 | 参见合并的参考文档： 221 | 222 | * 223 | * 224 | 225 | 冲突产生，是由于两个开发人员，修改了同一个文件。解决办法: 226 | 227 | git fetch origin 228 | git rebase origin/master 229 | 230 | git合并能力很强，一般的冲突上面可以自动解决了。如果冲突在同一个地方，需要手工解决。这个情况，请联系资深工程师帮助一起解决。需要用编辑器修改相应文件, 然后标志这些文件冲突解决，继续rebase： 231 | 232 | git add -u 233 | git rebase --continue 234 | 235 | 最后递交审查： 236 | 237 | git commit -a --amend 238 | git review 239 | 240 | ## 私有分支的使用 241 | 242 | 私有分支的应用场景 243 | 244 | 1. 在正式递交代码之前，开发调试往往需要和同事协同开发 245 | 2. 需要部署到测试机上进行测试, 但又不想递交到master 246 | 3. 个人在公司、家里、工地进行代码的同步 247 | 4. 个人需要开发一个较复杂的功能，在递交评审之前，需要频繁递交代码, 并且为了代码安全性，需要上传到远程备份 248 | 249 | 这时就需要使用gerrit的私有分支, 具体的步骤是： 250 | 251 | 私有分支的命名： 252 | 253 | dev/username/branchname 254 | 255 | 其中： 256 | 257 | * dev 私有开发分支的前缀，必须是 dev 258 | * username 你的 gerrit系统的用户名 259 | * branchname 你创建的私有分支名字，可以创建多个分支 260 | 261 | 创建本地的私有分支 262 | 263 | git checkout -b dev/refactor/fabric 264 | 265 | 开发，然后递交到本地，这个和普通开发一样 266 | 267 | 上传到 gerrit，并自动同步到 公司的官方git源（一般叫origin) 268 | 269 | git push gerrit HEAD:dev/refactor/fabric 270 | 271 | 其他同事切换到这个私有分支，并且获取刚才的修改 272 | 273 | git fetch origin 274 | git checkout dev/refactor/fabric 275 | git pull 276 | 277 | 在这里可以进行修改和递交，实现协同开发和代码同步 278 | 279 | 这个分支，经过测试以后，准备递交评审之前，一般使用 rebase 进行适当的合并, 然后递交 280 | 281 | git rebase -i HEAD~10 282 | git review 283 | 284 | 如果这个分支不再需要了，删除这个分支(本地和远程) 285 | 286 | git push gerrit :dev/refactor/fabric 287 | git checkout master 288 | git branch -d dev/refactor/fabric 289 | 290 | ## fabric的使用 291 | 292 | 为了提供工作效率，降低出错的几率，重复性的工作，尽量使用 fabric自动部署工具： 293 | 294 | * 生产机上的部署 295 | 296 | fab 297 | 298 | * 测试分支的部署 299 | 300 | fab branch:dev/refactor/fabric deploy 301 | 302 | ## 版本管理规则 303 | 304 | ### 一般线上运行的系统，只采用一个 master 主线的方式进行管理 305 | 306 | 也就是开发人员的代码，通过评审以后，直接merge到master分支；master分支也是生产机上运行的代码。这就要求有质量控制过程，防止错误导致系统的严重错误。 307 | 308 | * 递交的代码，要是一个原子操作，具有高内聚性，即一次递交的所有代码完成且仅完成一个功能，联系紧密，缺一不可 309 | * 递交的代码，要具有上线标准，要是一个可运行的合格的代码 310 | * 评审一般都必须至少一个以上的人评审过，最好是同组的开发人员评审，项目经理或者资深开发人员审批。评审的过程，也是结对编程的思想，可以互相熟悉代码，互相学习提高，便于统一代码风格，提高代码质量。 311 | 312 | ### 如果一个 feature 是一个需要较长时间开发，比如增加一个短信验证的功能，需要一周时间 313 | 314 | 在自己的这个开发分支内，可以采取小步快跑的方式不断递交到本地的git。在开发完成以后，在上传到 review服务器进行评审前，需要使用 rebase 命令，将这些多次递交适当进行合并然后上传。 315 | 316 | 记住，每一次递交在Gerrit评审服务器上，都必须要单独评审审批，如果一个功能有很多小的修改组成，这些小的修改可以适当合并，具体方法是： 317 | 318 | git checkout master 319 | git pull origin master 320 | git checkout your-feature-branch 321 | git rebase -i master 322 | 323 | ### 如果需要进行改版，会延续几个月的大量改进 324 | 325 | 需要在 gerrit 评审系统内创建新的开发分支，比如devel分支，而不使用 master 进行管理，以便进行代码的隔离。改版完成以后，将代码从develp合并到master分支。 326 | 327 | 这时，改版递交代码和评审，都在develop分支进行，上传命令采用； 328 | 329 | git review develop 330 | 331 | 生产机上任然使用 master分支。 这时，一般性的功能改进和bug修正，仍然递交到 master 分支。并且定时从 master merge到develop分支，以便减少冲突，降低以后 develop合并到 master的难度。 332 | 333 | 334 | ## FAQ 335 | * 评审没有通过，但是原有开发分支已经删除，如何恢复这个分支，继续修改代码 336 | 337 | 在gerrit上找到这个评审单，定位到响应的patchset，里面有获取代码、恢复分支的方式链接, 比如： 338 | 339 | git fetch ssh://refactor@review.bitcomm.cn:29418/testing refs/changes/07/7/1 && git checkout FETCH_HEAD 340 | git checkout -b my_branch 341 | 342 | * 如何获取通知邮件 343 | 344 | 对于关注的项目，可以获取通知邮件，方法是选择菜单： 345 | 346 | Settings - Watched Projects 347 | 348 | 然后使用 Browse 按钮选择响应的项目，然后选择“Email Notifications”的类型，一般全部打勾 349 | 350 | * 如何gerrit评审系统的键盘快捷键 351 | 352 | gerrit是google开发的软件，同样支持Google风格的快捷键，类似Gmail的风格。使用快捷键，可以提高阅读和评审的速度。使用问号 "?" 可以寻求快捷键的帮助。 353 | 354 | * 提示"Missing Change-Id in commit message" 355 | 356 | 这是由于没有下载hook, 生成Change-Id。这个Change-ID是gerrit一个必须的重要标志，多次修改同一个问题的时候，会对应到一个单子。解决方法。 357 | 358 | scp -P 29418 refactor@review.bitcomm.cn:hooks/commit-msg .git/hooks/ 359 | 360 | 然后再次递交： 361 | 362 | git commit -a --amend 363 | git review 364 | 365 | * Backporting a change to other branches 366 | 367 | 比如，一个master分支，一个release分支，递交进入master的分支中，有某个bugfix或者新特性需要合并回release分支： 368 | 369 | 370 | 371 | git fetch --all 372 | git checkout -b rfc/4-4/1234 origin/ 373 | git cherry-pick 374 | 375 | 去掉Change-Id, Reviewed-*, Tested-by等日志信息 376 | 377 | git commit -a --amend 378 | git review 379 | 380 | ## 一些场景 381 | 382 | ### 前端工程师如何递交代码？ 383 | 384 | 如果和程序员一起配合做一个功能，那么将代码交给程序员，开发、测试以后，一起作为一个原子操作递交。 385 | 386 | 如果是前端修改一个错误或者改进，不需要和程序员配合，则直接递交。 387 | 388 | -------------------------------------------------------------------------------- /build.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | echo "Pretending to build ..." 4 | echo "done" 5 | -------------------------------------------------------------------------------- /hello.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | #-*- coding: utf-8 -*- 3 | """ 4 | 测试模块，请尽量修改这个文件进行测试. 5 | 6 | Created on 2012-10-31 7 | 8 | @author: Peng Yong 9 | """ 10 | 11 | from datetime import datetime, date 12 | 13 | print "---------------begin---------------" 14 | print "hello world, gerrit2!" 15 | print "datetime: %s" % datetime.now() 16 | print "date: %s" % date.today() 17 | print "end" 18 | 19 | print "test of pengyong" 20 | print "migrating..." 21 | print "test of gpg signs" 22 | --------------------------------------------------------------------------------