32.10.5　重新提交新的补丁集

提交者收到代码被打回的邮件，一定很难过。不过这恰恰说明了这个软件过程已经相当的完善，现在发现问题总比在集成测试时甚至被客户发现要好得多吧。

根据评审者和检验者的提示，开发者对代码进行重新修改。下面的Bugfix过程仅仅是一个简单的示例，Bugfix没有这么简单的，对吗？;-)

$echo "fixed"＞＞readme.txt

重新修改后，需要使用—amend参数进行提交，即使用前次提交的日志重新提交，这一点非常重要。因为这样就会对原提交说明中的"Change-Id:"标签予以原样保留，当再将新提交推送到服务器时，Gerrit不会为新提交生成新的评审任务编号，而是重用原有的任务编号，将新提交转化为老评审任务的新补丁集，具体操作过程如下。

（1）在执行git commit—amend时，可以修改提交说明，但是注意不要删除Change-Id标签，更不能修改它。

$git add-u

$git commit—amend

readme.txt hacked with bugfix.

Change-Id:Id7c9d88ebf5dac2d19a7e0896289de1ae6fb6a90

Signed-off-by:Jiang Xin＜jiangxin@moon.ossxp.com＞

Please enter the commit message for your changes.Lines starting

with '#' will be ignored,and an empty message aborts the commit.

On branch master

Your branch is ahead of 'origin/master' by 1 commit.

#

Changes to be committed:

(use "git reset HEAD^1＜file＞…"to unstage)

#

modified:readme.txt

#

（2）提交成功后，执行git ls-remote命令会看到Gerrit维护的Git库中只有一个评审任务（编号1），且该评审任务只有一个补丁集（Patch Set 1）。

$git ls-remote origin

82c8fc3805d57cc0d17d58e1452e21428910fd2d HEAD

c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1

82c8fc3805d57cc0d17d58e1452e21428910fd2d refs/heads/master

（3）把修改后的提交推送到Gerrit管理下的Git版本库中。注意依旧推送到refs/for/master引用中。

$git push origin HEAD:refs/for/master

Counting objects:5,done.

Writing objects:100%(3/3),353 bytes,done.

Total 3(delta 0),reused 0(delta 0)

To ssh://localhost:29418/hello.git

*[new branch]HEAD-＞refs/for/master

（4）推送成功后，再执行git ls-remote命令，会看到唯一的评审任务（编号1）有了两个补丁集。

$git ls-remote origin

82c8fc3805d57cc0d17d58e1452e21428910fd2d HEAD

c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1

1df9e8e05fcf97a46588488918a476abd1df8121 refs/changes/01/1/2

82c8fc3805d57cc0d17d58e1452e21428910fd2d refs/heads/master