有关git的參考资料

• pro git中文版, 最好的git书籍

http://git-scm.com/book/zh

• 图解git

http://marklodato.github.com/visual-git-guide/index-zh-cn.html

• git交互式学习

http://try.github.com/levels/1/challenges/1

• Git分支管理策略

http://blog.jobbole.com/23398/

• type3的关于git和Gerrit资料

http://wiki.typo3.org/Git_Gerrit

• egit 和 gerrit的实践应用

http://wiki.typo3.org/Contribution_Walkthrough_with_EGit

有关gerrit
的參考资料

• http://gerrit-documentation.googlecode.com/svn/Documentation/2.5/intro-quick.html
• http://www.slideshare.net/lucamilanesio/gerrit-code-review
• http://qt-project.org/wiki/Gerrit-Introduction
• http://wiki.typo3.org/Contribution_Walkthrough_with_CommandLine
• http://wiki.whamcloud.com/display/PUB/Using+Gerrit
• http://wiki.openstack.org/GerritWorkflow
• http://wiki.openstack.org/GerritJenkinsGithub
• http://www.itk.org/Wiki/ITK/Git/Develop#Create_a_Topic
• http://openstack-ci.github.com/publications/jenkins/
• http://source.android.com/source/life-of-a-patch.html
• http://www.infoq.com/cn/articles/Gerrit-jenkins-hudson

注冊帐号

在http://review.bitcomm.cn注冊用户，採用的是openid统一认证。直接使用公司的google邮箱就能够了。

注冊的时候，注意:

• 设置自己的username。必须为英文或者数字，这个后面授权须要用到，比方我选择的是 refactor
• 导入自己的公钥，这个在 git 进行 review操作的时候。授权须要用到

注冊完了以后，能够看到 testing 项目，能够进行练习和測试。

其余的项目，联系项目经理进行授权，将以下的信息发送给项目经理：

注冊的邮箱、ssh公钥和相应的项目

工具安装

Windows

• 安装git 工具

因为眼下git的命令行功能和稳定性比图形界面的egit等强，大家在代码递交时。还是使用Windows或者Linux的命令行，windows下能够採用：

windows下的命令行工具：

http://msysgit.github.com

windows下的图形工具：

https://code.google.com/p/tortoisegit/

下载安装windows版本号的python。一般能够选用2.7.3

http://www.python.org/download/releases/2.7.3/

下载安装windows版本号的setuptools

http://pypi.python.org/pypi/setuptools

下载、解压、安装 pip 软件

http://pypi.python.org/pypi/pip#downloads

进入解压以后的文件夹，然后运行安装：

python setup.py install

使用pip安装 fabric 和 git-review

pip install fabric git-review

Ubuntu

sudo aptitude install python-pip

sudo pip install fabric git-review

CentOS

sudo yum -y install python-setuptools  python-devel python-pip

sudo pip-python install fabric git-review

导出项目，初始设置

配置递交代码人信息：

git config --global user.name "Peng Yong"

git config --global user.email ppyy@pubyun.com

从git取出代码：

git clone ssh://git@git.bitcomm.cn:2203/testing.git

注意选用自己须要的项目名称替代 testing

设置git review 系统, 第一次须要回答一个username，就是你在review系统的username

git review -s

假设没有安装 git review 软件包。则手工设置：

git remote add gerrit ssh://refactor@review.bitcomm.cn:29418/testing.git

scp -P 29418 refactor@review.bitcomm.cn:hooks/commit-msg .git/hooks/

注意:

• 选用自己须要的项目名称替代 testing
• 使用自己的username替代 refactor

日常开发流程

当须要改动一个bug，或者开发新功能时, 须要分几部：

获取最新的代码, 防止和他人冲突

git fetch origin

每个开发（bug。feature），都创建一个独立的开发分支。不要在 master上做，一般一个单元开发创建一个分支，互相不混淆。否则假设评审不通过。又一次改动会麻烦：

git checkout -b dev/username/typefix

git checkout -b dev/username/login_module

改动代码。然后检查代码：

git status

git diff

假设要放弃commit，使用 ：

git reset --soft HEAD^

本地递交代码:

git commit –a

注意。看一下这些文件是否都要递交，写好简要、清晰的递交日志。

上传代码。等待评审：

git review

假设没有安装 git review 软件。则手工上传。等待评审：

git push gerrit HEAD:refs/for/master

假设代码审查通过。合并完毕以后，能够删除这个分支：

git checkout master

git branch -d dev/username/typefix

假设评审不通过，须要再次改动代码，则继续在原来的分支改动代码

切换到原来的开发分支：

git checkout bug/typefix

改动代码…

然后递交（注意，一定使用 amend选项，这样能够继续递交在原来的review单号上）

git commit -a --amend

上传代码等待审批

git review

假设没有安装 git review 软件，则手工上传，等待评审：

git push gerrit HEAD:refs/for/master

假设代码审查通过，合并完毕以后，能够删除这个分支：

git checkout master

git branch -d bug/typefix

审批通过以后。gerrit提示有冲突怎么办

參见合并的參考文档：

• http://unethicalblogger.com/2010/04/02/a-rebase-based-workflow.html
• http://www.mediawiki.org/wiki/Gerrit/resolve_conflict

冲突产生。是因为两个开发者，改动了同一个文件。

解决的方法:

git fetch origin

git rebase origin/master

git合并能力非常强，一般的冲突上面能够自己主动攻克了。假设冲突在同一个地方，须要手工解决。

这个情况，请联系资深project师帮助一起解决。

须要用编辑器改动对应文件, 然后标志这些文件冲突解决，继续rebase：

git add -u

git rebase --continue

最后递交审查：

git commit -a --amend

git review

私有分支的使用

私有分支的应用场景

1. 在正式递交代码之前，开发调试往往须要和同事协同开发
2. 须要部署到測试机上进行測试, 但又不想递交到master
3. 个人在公司、家里、工地进行代码的同步
4. 个人须要开发一个较复杂的功能，在递交评审之前，须要频繁递交代码, 而且为了代码安全性，须要上传到远程备份

这时就须要使用gerrit的私有分支, 详细的步骤是：

私有分支的命名：

dev/username/branchname

当中：

• dev 私有开发分支的前缀，必须是 dev
• username 你的 gerrit系统的用户名
• branchname 你创建的私有分支名字，能够创建多个分支

创建本地的私有分支

git checkout -b dev/refactor/fabric

开发。然后递交到本地，这个和普通开发一样

上传到 gerrit，并自己主动同步到 公司的官方git源（一般叫origin)

git push gerrit HEAD:dev/refactor/fabric

其它同事切换到这个私有分支，而且获取刚才的改动

git fetch origin

git checkout dev/refactor/fabric

git pull

在这里能够进行改动和递交。实现协同开发和代码同步

这个分支，经过測试以后，准备递交评审之前。一般使用 rebase 进行适当的合并, 然后递交

git rebase -i HEAD~10

git review

假设这个分支不再须要了，删除这个分支(本地和远程)

git push gerrit :dev/refactor/fabric

git checkout master

git branch -d dev/refactor/fabric

fabric的使用

为了提供工作效率，减少出错的几率。反复性的工作。尽量使用 fabric自己主动部署工具：

• 生产机上的部署

  fab

• 測试分支的部署

  fab branch:dev/refactor/fabric deploy

版本号管理规则

一般线上执行的系统，仅仅採用一个
master 主线的方式进行管理

也就是开发者的代码。通过评审以后，直接merge到master分支；master分支也是生产机上执行的代码。这就要求有质量控制过程，防止错误导致系统的严重错误。

• 递交的代码。要是一个原子操作，具有高内聚性，即一次递交的全部代码完毕且仅完毕一个功能，联系紧密，缺一不可
• 递交的代码，要具有上线标准，要是一个可执行的合格的代码
• 评审一般都必须至少一个以上的人评审过，最好是同组的开发者评审，项目经理或者资深开发者审批。

  评审的过程，也是结对编程的思想，能够互相熟悉代码，互相学习提高，便于统一代码风格。提高代码质量。

假设一个
feature 是一个须要较长时间开发。比方添加一个短信验证的功能，须要一周时间

在自己的这个开发分支内。能够採取小步快跑的方式不断递交到本地的git。

在开发完毕以后。在上传到 reviewserver进行评审前，须要使用 rebase 命令。将这些多次递交适当进行合并然后上传。

记住，每一次递交在Gerrit评审server上。都必需要单独评审审批。假设一个功能有非常多小的改动组成。这些小的改动能够适当合并。详细方法是：

git checkout master

git pull origin master

git checkout your-feature-branch

git rebase -i master

假设须要进行改版。会延续几个月的大量改进

须要在 gerrit 评审系统内创建新的开发分支，比方devel分支，而不使用 master 进行管理，以便进行代码的隔离。

改版完毕以后，将代码从develp合并到master分支。

这时，改版递交代码和评审，都在develop分支进行。上传命令採用。

git review develop

生产机上任然使用 master分支。 这时。一般性的功能改进和bug修正，仍然递交到 master 分支。而且定时从 master merge到develop分支。以便降低冲突，降低以后 develop合并到 master的难度。

FAQ

• 评审没有通过，可是原有开发分支已经删除。怎样恢复这个分支，继续改动代码

在gerrit上找到这个评审单。定位到响应的patchset，里面有获代替码、恢复分支的方式链接, 比方：

git fetch ssh://refactor@review.bitcomm.cn:29418/testing refs/changes/07/7/1 && git checkout FETCH_HEAD

git checkout -b my_branch

• 怎样获取通知邮件

对于关注的项目。能够获取通知邮件，方法是选择菜单：

Settings - Watched Projects

然后使用 Browse button选择响应的项目，然后选择“Email Notifications”的类型，一般所有打勾

• 怎样gerrit评审系统的键盘快捷键

gerrit是google开发的软件，相同支持Google风格的快捷键。类似Gmail的风格。

使用快捷键。能够提高阅读和评审的速度。使用问号 "?

" 能够寻求快捷键的帮助。

• 提示"Missing Change-Id in commit message"

这是因为没有下载hook, 生成Change-Id。这个Change-ID是gerrit一个必须的重要标志，多次改动同一个问题的时候，会相应到一个单子。解决方法。

scp -P 29418 refactor@review.bitcomm.cn:hooks/commit-msg .git/hooks/

然后再次递交：

git commit -a --amend

git review

• Backporting a change to other branches

比方。一个master分支，一个release分支，递交进入master的分支中。有某个bugfix或者新特性须要合并回release分支：

http://wiki.typo3.org/Contribution_Walkthrough_with_CommandLine

git fetch --all

git checkout -b rfc/4-4/1234 origin/<release-branch>

git cherry-pick <revision-id>

去掉Change-Id, Reviewed-*, Tested-by等日志信息

git commit -a --amend

git review <release-branch>