代码改变世界

Git push remote rejected {change ### closed}

2018-09-01 19:04  加个小鸡腿  阅读(10077)  评论(0编辑  收藏  举报

是因为和关掉的提交对应的Change_id一样导致的。

另一种可能是cherry-pick导致的:

之前提交的时候因为有merge,所以在gerrit服务器上审核的时候,我给abandoned了,因此从新处理提交的时候就出现了相同的tree, parent, author, committer以及log原文,这也就不难怪change-id也相同了。

添加一次可能导致Change-ID相同的情况,新的分支的提交是从另外的分支上cherry-pick过来的,所以当abandoned一次之后,再次cherry-pick时,Change-ID作为提交记录一并cherry-pick过来了,所以会重复。

 

简单的办法就是执行git commit --amend 删掉change_id就可以了,保存退出后会自动生成一个新的change_id,再次执行push就可以推到库了。

参考:

https://stackoverflow.com/questions/11972384/git-push-remote-rejected-change-closed

 

如果上面删除Change-Id的办法不可行,即git commit --amend 删除以后还是不行,我查资料看有些人说用git push -f   强推,我并不喜欢这种方式,不安全,真正我连尝试都没尝试就否定了他,然后我又想丢掉最后的提交记录重新提交可以不,执行git reset --soft HEAD~1 ,再git commit -m "commit again"写点信息,git push  还是报一样的错,

那怎么办呢?这里我建议采用生成补丁,打补丁的方式来重新提交,这是个安全可靠的方法,并且完全可行,可参考我的另一篇博客:

linux git patch 和patch以及git diff 命令

这里介绍下详细过程:

比如你执行了git  log -3 看到以下三个提交,最后的id3就是你提交不上的

commit id3

commit id2

commit id1

步骤:

(1)生成补丁:git format-patch -1 commit_id2  commit_id3    生成以后比如叫00001-commit-id1.patch  ,然后看看这个补丁的改动对应的是不是你的id3的修改

(2)移动补丁到工程外:mv 00001-commit-id1.patch   /root/    【目录随便选,但是要在工程目录外】

(3)确定无提交后版本硬回退,并pull最新代码,git reset --hard HEAD~3;   git pull

         注意,一定要确定没有要提交的代码了,因为--hard会把你的未提交的修改都丢掉。

(4)移动补丁回工程目录下:mv /root/00001-commit-id1.patch  ./

(5)检查补丁是否可用: git apply --stat 00001-commit-id1.patch

(6)打补丁:git am 00001-commit-id1.patch

(7)执行git log 看看是否打成功了,执行git show 看看修改对不对

(8)提交到gerrit:【比如要提交到develop分支】 git push origin HEAD:refs/for/develop