本文整理向openstack社区提交代码的基本流程,以及社区一些介绍资料。如有转载,请注明出处!

  先放张图说明一下OpenStack的code review的大体流程:

  对OpenStack提交代码更改的流程主要如下:

  • 配置Git与Gerrit环境
  • 克隆目标项目的代码并在新branch上进行更改
  • commit到本地的repo后推送给远端Gerrit,然后由reviewer给出意见
  • 根据reviewer的修改意见不断更新patch

  其中OpenStack使用Gerrit作为代码review系统,使用Jenkins系统对代码进行自动测试,使用tox工具可以在本地进行相同的代码测试。

基本前提

  1. 创建一个Launchpad账号(Gerrit使用Launchpad进行SSO)
  2. 登录Gerrit,完成基本配置
  3. 加入OpenStack基金会
  4. 签署Contributor License Agreement
  5. 安装 Git 和 git review

  本文所有操作在Ubuntu Server 14.04 LTS上进行

配置Git

  首先配置Git命令行工具,便于以后的操作

$ git config --global user.name 'YourName'
$ git config --global user.email example@example.com
$ git config --global gitreview.username YourName

  如果需要查看Git的配置:

$ gir config --list

安装配置Git-Review

  1. git-review工具是一组Git子命令,主要用于和OpenStack的代码review系统Gerrit交互,git-review和Gerrit的交互是一组Git命令,在每个git review命令后添加-v选项可以打印所有运行的Git命令。

$ sudo apt-get install git-review

  2. 在你要提交代码的机器上生成一个SSH key:

 $ ssh-keygen –t rsa 

  如果创建RSA密钥时设置了口令,该口令需要妥善保管,因为以后每一次提交都需要验证该口令。

  3. 查看公钥部分并将其复制到git-review:

$ less ~/.ssh/id_rsa.pub

  将公钥部分的内容添加到git-review即可。

在本地克隆代码库

  1. 克隆源码
$ git clone https://github.com/openstack/YourTargetProjectName.git
  1. 进入到克隆后的目录
$ cd YourTargetProjectName
  1. 建立git review 环境
$ git review -s

This repository is now set up for use with git-review. You can set the default username for future repositories with:
git config --global --add gitreview.username yourgerritusername
  1. 可以在Git中设置Gerrit/Launchpad的用户名,
$ git config --global --add gitreview.username YourName
  1. check out 到master分支,更新远端并将其pull到本地的master分支
$ git checkout master; git remote update; git pull origin master

  6. 在Launchpad上report 一个新的bug, 或者找一个尚未被解决的bug然后将它assign给自己,将bug的状态改为In progress, OpenStack使用Launchpad记录Blueprints和报告bugs。

  7. 想要fix某个bug,就必须新建一个分支,然后在这个分支里对源代码进行修改,例如:

$ git checkout -b fix-bug-#
  1. 上述命令创建并切换到新分支“fix-bug-#123456”,接下来所有的本地工作在这个分支里进行,直到所有fixation都完成后再commit,
$ git commit -a

  提交时会要求输入commit message,commit message可以有下面的字段:

  Implements: blueprint BLUEPRINT

  Closes-Bug: #123456

  Partial-Bug: #123456

  Related-Bug: #123456

  通过这些字段来标识自己工作相关的bug或者blueprint,一旦注明,CI系统会自动将你的commit和相同ID的bug对应起来。

  1. 上面的命令提交到本地repo后接下来就是push到Gerrit了。
$ git review -v

  Gerrit是OpenStack远端Git仓库的一道大门,所有的submission都要在这里经过review后才能被merge到master分支中,因此之前的工作一定不能在master分支进行,这样会产生一个merge commit,Gerrit默认是不接受merge commit的。

  如果提交成功,Gerrit将返回一个显示你此次提交内容的URL,打开它就可以查看commit以及reviewer的评价了:http://review.openstack.org/nnnnnn

如果需要修改commit怎么办?

  此时需要到http://review.openstack.org上查找自己的patch记录,然后记下这一个patch的review number,就是review.openstack.org对应patch页面的后几位数字:https://review.openstack.org/#/c/nnnnnn/

$ cd ourTargetProjectName    #切换到项目源码目录
$ git review -d nnnnnn #把patch给check out,然后就可以编辑了

  接着根据reviewer们的意见重新编辑patch,然后提交

$ git commit -a --amend    #在本地commit
$ git review

  对上一次的commit进行了修改,或者commit message没有写标准,都可以重新提交commit,但是一定要切换到自己上次提交commit的分支执行上面的命令。如果希望查看完整的git命令流,可以在git review命令后添加 -v选项。

-- ::50.927128 Running: git log --color=never --oneline HEAD^..HEAD
-- ::50.930189 Running: git remote
-- ::50.932609 Running: git branch -a --color=never
-- ::50.935309 Running: git rev-parse --show-toplevel --git-dir
-- ::50.937601 Running: git remote update gerrit
Fetching gerrit
-- ::04.406800 Running: git rebase -i remotes/gerrit/master
-- ::04.507110 Running: git reset --hard ORIG_HEAD
-- ::04.514952 Running: git config --get color.ui
-- ::04.517383 Running: git log --color=always --decorate --oneline HEAD --not remotes/gerrit/master --
-- ::04.523654 Running: git branch --color=never
-- ::04.526527 Running: git log HEAD^..HEAD
Using local branch name "fix-bug-123456" for the topic of the change submitted
-- ::04.530764 Running: git push gerrit HEAD:refs/publish/master/fix-bug-
remote: Processing changes: updated: , refs: , done
remote: (W) 81a1233: commit subject > characters; use shorter first paragraph
remote: (W) 81a1233: no files changed, message updated
To ssh://YourName@review.openstack.org:29418/openstack/TargetProject.git
* [new branch] HEAD -> refs/publish/master/fix-bug-
-- ::11.126958 Running: git rev-parse --show-toplevel --git-dir

一些Troubleshoot,

  如果配置Git或Gerrit的过程中遇到了问题,https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers的最后提供了常见问题的troubleshoot,可以参考。

OpenStack的Commit Message风格,

  这里对于每一次提交commit时commit message的风格有一定的介绍:https://wiki.openstack.org/wiki/GitCommitMessages

OpenStack的bug分流,

  这里有OpenStack对不同程度的bug进行分流的介绍:https://wiki.openstack.org/wiki/BugTriage

OpenStack的bug分类,

  OpneStack根据状态、重要程度等指标对Bug进行分类:https://wiki.openstack.org/wiki/Bugs

OpenStack的blueprints,

  WIKI介绍:https://wiki.openstack.org/wiki/Blueprints

  Launchpad上的OpenStack项目首页:https://blueprints.launchpad.net/openstack

OpenStack所有项目的Spec,

  specifications记录了每个项目的设计规范,这里是所有项目的Specs:http://specs.openstack.org/

OpenStack的发行周期,

  这里是关于发行周期的一些介绍,https://wiki.openstack.org/wiki/ReleaseCycle

  所有OpenStack项目的分支tar包:http://tarballs.openstack.org/

OpenStack代码分支模型,

  这里是代码分支模型的介绍,https://wiki.openstack.org/wiki/Branch_Model

OpenStack提交代码的review流程的更多相关文章

  1. Git提交代码的处理流程(转)

    Jerry 工作在wchar_support分支.他改变了名称的功能和测试后,他提交他的变化. [jerry@CentOS src]$ git branch master * wchar_suppor ...

  2. git提交代码托管平台流程

    首先先安装git git官网 ---- https://git-scm.com/ 下载好傻瓜式安装即可 安装好过后,再桌面任意空白区域右键,看到以下两个选项即为安装成功 一般都用第二个选项也就是 Gi ...

  3. Pull Request的过程、基于git做的协同开发、git常见的一些命令、git实现代码的review、git实现版本的管理、gitlab、GitHub上为开源项目贡献代码

    前言: Pull Request的流程 1.fork 首先是找到自己想要pull request的项目, 然后点击fork按钮,此时就会在你的仓库中多出来一个仓库,格式是:自己的账户名/想要pull ...

  4. github提交代码流程:

    (1)  检查一遍代码改动          $git status (2) 将工作目录中的代码提交到暂存区 $ git add filename     git add -A (3)  提交代码到本 ...

  5. Git和Code Review流程

    Code Review流程1.根据开发任务,建立git分支, 分支名称模式为feature/任务名,比如关于API相关的一项任务,建立分支feature/api.git checkout -b fea ...

  6. GIT入门笔记(20)- git 开发提交代码过程梳理

    git开发提交流程新项目开发,可以直接往master上提交老项目维护,可以在分支上修改提交,多次add和commit之后,也可以用pull合并主干和本地master,解决冲突后再push 1.检出代码 ...

  7. 使用Android Studio向GitHub提交代码

    使用Android Studio向GitHub提交代码 在GitHub上创建一个仓库 填写仓库名称.描述.类型(公有.私有)等信息,点击创建 到此,成功创建了我们的仓库,并且初始化创建了README. ...

  8. 向Github提交代码时遇到的一些问题

    今天分享一下我的一些小经验,那就是向github提交我们的代码.之前一直是直接使用的浏览器完成的代码的下载任务,没有使用过客户端,为了让自己在工作之前熟练使用GitHub,所以就有了下面的这篇博文了. ...

  9. git 提交代码操作

    1.修改1分支后 git add git commint2.切换到本地分支git checkout local-5.0git remote update 更新远程仓库3.git pull origin ...

随机推荐

  1. python2/3 中删除字典中value为空的键值对方法

    python2 data_info = { 'account': 1, 'remark': 2, 'sort': '', 'weight': '', } for key in data_info.ke ...

  2. #pragma pack(push) 和#pragma pack(pop) 以及#pragma pack()

    我们知道结构体内存对齐字节可以通过#pragma pack(n) 的方式来指定. 但是,有没有想过一个问题,某些时候我想4字节对齐,有些时候我又想1字节或者8字节对齐,那么怎么解决这个问题呢? 此时, ...

  3. 分页用到的子查询sql语句

    说明(2017-8-31 23:30:22): 1. 分页用到的子查询sql语句 select * from(select *,ROW_NUMBER() over(order by id)as num ...

  4. [转]使用Navicat导入导出数据库表

    原文地址:https://blog.csdn.net/anselandevil/article/details/81667199 步骤1:数据中原始数据如下: 点击表,右键选择导出向导,选择导出为sq ...

  5. [WPF源码分析]ContentControl依赖项属性的双向绑定,two-way binding view's DependencyProperty and ViewModel's variable

    问题:自定义控件的依赖项属性和VIewModel中的变量不能双向绑定 解决思路:对比.net源码 PresentationFramework  /   System.Windows.Controls ...

  6. [wdt]watchdog

    board/ti/am335x/board.c board/ti/am43xx/board.c driver/watchdog/omap_wdt.c include/configs/am43xx_ev ...

  7. Linux环境下NodeJS和MongoDB的安装配置

     一.NodeJS的安装配置 #进入安装目录cd /usr/local/ #删除原有安装rm -rf noderm -rf node-v0.10.29-linux-x64 #解压压缩包tar -zxv ...

  8. SpringBoot 开启 Actuator

    在生产环境中,需要实时或定期监控服务的可用性.spring-boot 的actuator(监控)功能提供了很多监控所需的接口.简单的配置和使用如下: 1.引入依赖: <dependency> ...

  9. ubuntu下IDEA配置tomcat报错Warning the selected directory is not a valid tomcat home

    产生这个问题的主要原因是文件夹权限问题. 可以修改文件夹权限或者更改tomcat文件目录所有者. 这里我直接变更tomcat文件夹所有者: sudo chown -R skh:skh tomcat-/ ...

  10. OSPF邻居状态机

    当OSPF邻居建立的过程之中,路由器在和邻居达到完全邻接关系之前,要经过几个状态.这些状态在OSPF RFC2328有相关的定义,这些状态分别是Down, Attempt, Init, 2-Way, ...