《Commit Checklist for Chromium Workflow》

资料：《Commit Checklist for Chromium Workflow》

---

Commit Checklist for Chromium Workflow

在上传change lists(CLs) on Gerrit和code review之前，浏览本文档清单是很有用的。Gerrit是chromium项目的code review platform。目标受众是不熟悉 contributing to Chromium project的software engineer

Checklist是强大给工具，可以确保工作的高效性，不至于过多的大脑能量去确认下一步的工作内容

1.Create a new branch or wwitch to the correct branch

在开始开发之前，先创建一个新的分支

git new-branch <branch_name>

和下面的等价，但建议用下面的，好理解

git checkout -b <branch_name> 。等于创建一个分支并且切换到新分支

将assign到自己的crbug标记为 “started”，这样别人就知道你在修复了，避免重复工作

2.If there is a local upstream branch,rebase the upstream changes

假设有一个上游和下游分支，如果你在上游分支提交了些东西，并且希望在下游分支中出现 上游分支的修改，需要做：（自己先测试一下再问问题）

• git checkout downstream
• git rebase -i @{u} 拉上游分支到当前分支
• git rebase -i @{u} 再把下游的改变重新设置到上游上？？？ 不懂

会有大量的冲突要修改，完成后执行 git rebase --continue

3.Make you change

fix bug,finish feature

4.Make sure the code builds correctly

先本地进行测试，没问题后再提交，CQ(Commit Queue)可能要好几个小时

5.Test your change

LOG(ERROR) 可以输出错误信息，并且给error的地方加上断点
常见的edge case

• Guest mode
• Enterprise/EDU/ users
• Aaccessibility
• Ofiicial Chrome-branded build(for Googlers)

6.Write unit or browser tests for any new code

多做测试单元

7.Ensure the code is formatted nicely

> git cl format --js 可以格式化代码 平时会用吗？具体什么效果

8.Review your change

git diff能查看和在上次staged之后的改变
git upstream-diff，可以查看和上游的所有差别

9.stage relevant files for commit

git add filepath

10.Commit your change

git commit [-a] -m “Comments”

11.Squash your commits

用rabase将多次commits，合成一次commit

12.Rebase your local repository

怎么和之前在Pro git里学的Rebase不太一样呢？
Rebase是一种巧妙的方法，同步远端仓库和解决change list 上的冲突
执行 > git rebase-update可以更新远端的更新到本地分支 == 纳尼，这个更诡异了 ==
并且会删除本地分支

通过gclient sync -D更新第三方库依赖

13.Upload the CL to Gerrit

使用> git cl issue确保上传正确的Gerrit CL。如果在上传一个新的CL，issue number是none
上传的时候要吧reviewers加上，一些注释，标题tilte之类的，便于reviewer的人看

14.Check the CL again in Gerrit

git cl web 打开对应的web页面，看看提交上去的内容对不对

先self-review，然后再找人review

15.Make sure all auto-regression tests pass

CQ Dry Run

查看是否通过CQ的测试

16.Add reviewers to review you code

Click Find Ownners 或者 git cl owners 去找到文件的拥有者review code。在Code Search中，可以找到熟悉这部分file and code owners

17.Start your review

click “Start Review” button

18.Implement feedback from reviewers

和reviewer保持时刻的沟通

19.Land your CL

一旦获得Looks Good To Me（LGTM），代表有一个reviewer通过了。CL通过CQ，并不代表后续没问题了。 后续可能还会有BUG，请关注chromium的构建树网页

20.Cleanup

land成功后，执行 git rebase-update 或者 git cl archive。会自动删除合并的分支，标记相关的crbugs as “fixed”

---

感觉还是不太熟练，等后面碰到再说吧 orz…