Code Commit Flow

Contents

 [hide] 

• 1通用原则
• 2<步骤1> Bug ID
• 3<步骤2> Bug Ownership
• 4<步骤3> Git 初始化以及本地分支创建
• 5<步骤4> Patch Generation
• 6<步骤5> Peer Review
• 7<步骤6> Patch Commition
• 8<步骤7> Push to Server
• 9<步骤8> Close Bug
• 10<步骤9> Post Work
• 11补充
• 12再补充
• 13避免出现merge commit以及git变胖

通用原则[edit]

所有的代码提交都需要经过"开bug、开分支、提patch、review、提交信息确认、push到服务器、关闭bug"这一系列的阶段。

在IDE项目中，任何团队成员都可以push代码到小组仓库。能力越大, 责任越大。

请保证自己每次敲 git push origin branchname 的时候双手都是颤抖的 :-)

若能上网还不能访问bugzila和wiki 则需要在/etc/hosts 文件中添加“192.168.160.49 ide.nfs.iscas.ac.cn”。若用vi编辑时，在插入模式按动下上下左右键会出现abcd 时 则可以采用vim编辑安装vim命令为 sudo apt-get install vim

_

<步骤1> Bug ID[edit]

我们对代码的任何修改都应首先具有一个BugZilla上的Bug与之对应。

Bug的编号（ID）和Bug的标题（summary）将会成为代码提交信息（commit log）的第一行出现。

如果BugZilla中已有的bug中没有任何一个能够描述代码的修改，则创建一个新的bug，描述代码提交想要达到什么目的，需要进行什么修改。

提交信息的第一行类似于:

   "Bug XYZ - Summary of Bug XYZ. r=ReviewerNickName"

任何一次提交都需要对应一个 Bug ID, 而一个 Bug 可以拆分成多个 Patch (Commit) 来完成. 这个时候需要在 summary 之前加入patch的编号, 类似

    "Bug XYZ (Part 1) - Summary of Bug XYZ. r=ReviewerNickName"

<步骤2> Bug Ownership[edit]

当我们想要完成一个bug对应的任务（task，feature）或修复这个bug时，我们首先应该看一下这个bug的assignee是否为nobody。

当这个bug的assignee是nobody的时候，表示这个bug目前还没有人处理，你可以直接将assignee改成自己，然后就可以进行以下的步骤了。

反之，如果这个bug的assignee不是nobody，而是团队中另一个成员的名字，那么可能她（他）已经在工作了。

你需要在团队QQ群里（或在bug中回复）跟当前的assignee进行确认，如果对方没有时间完成这个bug，你可以take这个bug并提交自己的patch。

<步骤3> Git 初始化以及本地分支创建[edit]

现在你已经可以开始对代码进行修改了。为了正确的进行代码修改并提交patch，可以执行以下的命令，确保自己的本地working copy是干净的：

a) 首先查看自己的作者信息是否正确

>>git config --list

你应该看到自己的名字和邮箱。如果看不到，需要进行设置

>>git config --global user.name "YOUR NAME"

>>git config --global user.email "YOUR@EMAIL"

PS:如果是第一次进行修改， 需要先下载GDT代码仓库

>>git clone [e-mail]:/home/git/gdt.git

>>cd gdt

b)创建一个patches文件夹用来存放patch。这个文件夹不会被提交到git仓库。

>>mkdir patches

c)查看自己的分支是否在 master 上。（这个在 git status 中也能够看到）

>>git branch

d)查看自己的工作副本是否是 clean 的。如果不是，先尝试将其变成 clean 的。如果不确定怎么做,找队友求助。

>>git status

e)切换到 master 上， 如果当前的分支不是的话。

>>git checkout master

f)开一个本地的分支，用 Bug ID 命名。

>>git checkout -b bugXYZ

接下来就可以进行修改了

<步骤4> Patch Generation[edit]

在建立一个干净的本地分支之后，就可以进行代码的修改。

在代码修改之后，本地提交之前，需要生成一个patch，用于提交到BugZilla，请求团队其他人员Review。

# 修改代码、测试、修改、测试、修改。。。

# 在提交之前至少确保你的改动是能够编译通过，并通过helloworld测试。（FIXME：后续会有自动的单元回归测试）

# 查看自己的更改

>>git status

# 如果有新添加的文件， 尚未加入到git仓库中：

>>git add new-created-files

# 如果添加了新的文件，需要将所有的本地改动都提交到 stage 状态。否则生成的patch不完整。

>>git add file-have-been-modified

# 查看是否添加正确

>>git status

# 如果没有添加新的文件， 也没有后修改是在 stage 区域，那么使用以下的命令生成patch

>>git diff -U8 > patches/BugXYZ.patch

# 反之，如果都提交到了 stage 状态，则需要添加 --staged 参数。

>>git diff -U8 --staged > patches/BugXYZ.patch

然后就可以提交到BugZilla了

<步骤5> Peer Review[edit]

提交patch的时候需要注意以下的细节：

a）提交的时候需要起一个名字，名字尽量有意义。如果patch比较简单，也可以用“bugID“或”patch“作为名字；

b）文件类型需要选择为patch，这样能够通过BugZilla的splinter进行查看；

c）指定一个reviewer，并在团队QQ群中跟他（她）说一下，这样能够加快Review进度；

d）如果patch并没有准备好提交，只是希望能够得到一些反馈，不需要指定”review?“，指定”feedback?“就可以了。

名字可以是WIP（Work In Progress）。可以指定多个feedback developer。

等待Reviewer的回复。Reviewer会阅读你的patch并提出修改意见，修改意见会以评论的形式出现在BugZilla上。

你需要根据Reviewer的意见进行修改，并提交新的patch，直到你和Reviewer的意见达成一致。

在Reviewer同意了你的patch（给出了review+的反馈）之后，你就可以着手进行提交了。

<步骤6> Patch Commition[edit]

拿到Reviewer的r+反馈之后就可以准备进行提交了。

patch提交是比较容易出现错误的阶段，最常见从错误有两个。

<第一个错误>在本地分支中进行了多次提交（commit），在r+之后，直接通过 git merge 操作将本地分支的改动 merge 到了 master 上。

这样做可能会违反我们关于代码提交历史的要求，一方面提交信息没有包含Reviewer的信息，另一方面commit可能包含不一致或错误的状态。

（关于commit原则在另外的wiki中有详细规定）

<第二个错误>在进行提交时，工作区的修改混杂了非patch的修改内容。

这类错误常见于需要提交多个patch（一个bug的多个parts或者同时在修复多个bug）。

避免这两个错误的最简单的方法，是在一个干净的（clean）工作区上apply你自己的patch，进行提交。

# 跳回到 master 上

>>git checkout master

# 确保工作区是干净的。如果不是，上IDE开发群求助

>>git status

# 更新本地仓库，与远程仓库一致

>>git fetch -v

>>git merge origin/master

# 应用r+的patch

>>git apply patches/bugXYZ.patch

# 检查结果是否正确

>>git status

# 提交，填写提交信息（commit log）

>>git commit -a

如果在apply你的patch，或者在尝试merge你的branch的时候出现了问题，请在QQ上提问，并贴出截图供大家分析。

<步骤7> Push to Server[edit]

恭喜你，现在已经将你的patch提交到了本地仓库中。接下来需要push到小组服务器上。

# 双手颤抖的检查修改是否正确，提交信息是否对。在push到小组服务器之前始终有机会修改。

>>git log -n 5

>>gitk&

# 仔细的检查，是否在master上。

>>git branch

# 最后，push。注意要加上分支的名字

>>git push origin master

恭喜你提交了第一个patch！

<步骤8> Close Bug[edit]

提交之后就可以关闭对应的bug了。关闭时选择 resolve/fixed。

我们倾向于在关闭bug的时候将patch对应的commit id（hash）追加到bug的comment中。

如果使用 git-bz，可以自动的追加commit id到对应的bug上；如果没有使用 git-bz，则可以手动贴上去。这个不做要求。

<步骤9> Post Work[edit]

至此，一次完成的代码工作流程就结束了。

后续，如果在测试中发现你的提交引发了新的bug，那么需要REOPEN对应的bug，进行分析和修复。跳到步骤3（Patch Generation）开始新的修复。

补充[edit]

现在做一些更新/调整:

a) 提交到 BugZilla 上的 patch 可以请求别人 review, 给出评价了. 注意给评价的时候, "+" 就等于可以合并了, 要仔细些. (参考 bug 80/bug 11 的review.)

b) 拿到了 review+ 之后, 根据 reviewer 的修改意见就可以直接提交了. 这个时候,

b.1) 如果修改的代码不多, 多个commit可以作为一个 patch 直接打到 master 上, (使用 git apply 或者 patch -p1 命令);

b.2) 如果修改本身就是拆分成了几个 patch 提交到 BugZilla 让 reviewer 进行 review, 那么不应该合并, 应该按照 review 的结果提交;

b.3) 如果 patch 对应了几次 commit, 每次 commit 都是完成独立的目的, 那么也可以使用 merge 一次性将所有的提交都 push 到代码库中.

看着可能很复杂, 自己操作一遍就熟练了. ;-)

再补充[edit]

对于多个 patch 提交代码的处理方法及注意事项

注意事项：

1、每次开始写一个新的 patch 的时候，保证自己的 git status 返回的是空的 

2、如果之前改了一些内容（patch），但是没有提交， 是不能够直接写新的patch的（否则会需要进行patch分拆） 

3、另外一种方式是利用 git 的 staged/unstaged 两种状态 

以下为利用 git 两种状态处理多个 patch 提交的处理方法：

这种方式可以将 patch 拆成 1、2、3 等多个小的部分，最后提交的时候合并在一起提交 

例如对于 bug 621 而言，工作流可以是这样： 

>> git status #make sure it's clean 必须保证工作区是干净的，然后才可以修改代码！

   # modify code

>> git diff -U8 > patches/yourbugIDpart4.patch

   # upload the patch to bugzilla 将 patch 上传到 Bugzilla

>>  git status # 确保没有多余的文件出现

>>  git add  # 将当前的修改缓存到 git 的 staged 区

   # modify code 继续修改下一个 patch

>> git diff -U8 > patches/yourbugIDpart5.patch

   # upload the patch to bugzilla 将新的 patch 上传到 Bugzilla

>> git status # 确保没有多余的文件出现

>> git add  # 将当前的修改缓存到 git 的 staged 区

   # 就这么重复下去，最后

>> git commit -am 'bug XX (part 4 - 5) - XYZ, r=limei'

>> git push origin master

  #检查是否提交成功

>> git status

>> git diff

>> git add 

>> git diff -U8 --staged #能够看到已经缓存的修改

避免出现merge commit以及git变胖[edit]

产生这种不良情况的步骤：

1.本地master没有和origin master同步

2.切换到bug分支

3.git pull origin master

4.修改代码

5.commit

6.git变胖了，并且多了merge commit

现场抢救步骤：

1.切换到本地master，先和origin master保持一致： git reset --hard commit-id-you-want-to-restore

2.切换到bug分支，备份一下你修改的代码，然后让bug分支和master保持一致 git reset --hard commit-id-you-want-to-restore

3.清除workspace中产生的奇怪的无用代码

4.git add .

5.git commit 

完成以上步骤后，就不会变胖啦！

（吴伟的建议步骤：

在bug分支上，

reset hard 到你提交的那次commit

 git co master; git pull origin master; git co bugXXX;  git rebase master gitk& #check it again

）

原因分析：

master 需要始终跟 origin 的一致，否则就会出现pull的时候自动创建了一个merge commit

也就是说merge commit 只有在两个分支都有修改的时候才会出现，否则不会出现