gerrit "missing Change-Id"
10494 단어 소프트웨어 버전 관리
장면:
당신은git push로gerrit에 심사 대기 코드를 제출했습니다. 모든 것이 순조롭습니다. 당신의 머릿속에는'코드 머리에'부처님 보우'가 과연 유효하다'는 생각이 떠올랐습니다.이때git는 다음과 같은 알림을 출력하고 당신의 내면 OS는'기분-5'를 동시 출력합니다.
remote: Resolving deltas: 100% (14/14)
remote: Processing changes: refs: 1,done
remote: ERROR: missing Change-Idincommit message footer
remote:
remote: Hint: To automatically insert Change-Id,installthe hook:
remote: gitdir=$(git rev-parse --git-dir);scp-p -P 29418 [email protected]:hooks/commit-msg${gitdir}/hooks/
remote: And then amend the commit:
remote: git commit --amend
remote:
To ssh://[email protected]:29418/kaiba_admin_yunying.git
! [remote rejected] HEAD -> refs/for/master(missing Change-Idincommit message footer)
error: failed to push some refs to'ssh://[email protected]:29418/sample_project.git'올가미:
전제:commit-msg 파일은 이 프로젝트에 이미 존재해야 합니다.
ls 명령을 사용하여 파일이 있는지 확인합니다.
$ cd project_dir
$ ls.git/hooks/commit-msg파일이 존재하지 않으면 git push에 표시되는 프롬프트에 따라 파일을 가져옵니다.
$ gitdir=$(git rev-parse --git-dir);scp-p -P 29418 [email protected]:hooks/commit-msg${gitdir}/hooks/위의 명령은git push에서 발생한 오류 정보에서 직접 복사할 수 있습니다.만약 손으로 이 명령을 두드리려고 한다면, 사용자 이름을 자신의 것으로 바꾸는 것을 잊지 마라.
방법 1: amend 옵션을 사용하여 Change-ID를 생성합니다.
Change-ID가 없는 것이 마지막 (head) commit인 경우 다음 명령을 사용하여 문제를 해결할 수 있습니다.
$ git commit --amend이 명령은 기본commit 메시지 편집기를 엽니다. 보통vi입니다. 이 때 아무것도 수정하지 않고 종료를 저장하면 됩니다.
:wqgit log를 다시 한 번 살펴보면 부족한 Change-ID가 이미 보충되어 있음을 발견할 수 있습니다.다시git push하면 됩니다.메서드2: Change-ID가 마지막 commit이 아닌 경우 reset 메서드를 사용할 수 있습니다.
예를 들어 Change-ID의 commit이 git log의 두 번째 commit이 없으면 git reset 명령으로 로컬 분기를 이 commit로 되돌릴 수 있습니다.(그러나 그 실용적인git reset에서 Change-id를 되찾는 것은 보통 청년들이 할 수 있는 일이고 문예 청년들은 더욱 우아한 방법이 있다. 방법 3) 우선git log를 집행하고 Change-id가 부족한commit를 찾아내고commit-id를 복제한다.
$ git log
commit 8e1cad33bcd98e175cba710b1eacfd631a5dda41
Author: liux
Date: Mon Dec 19 17:43:00 2016 +0800
testcommit"with amended commit message"
Change-Id: I9d2af0cc31423cf808cd235de0ad02abf451937d
commit 1a9096a34322885ac101175ddcac7dab4c52665d
Author: liux
Date: Mon Dec 19 15:23:36 2016 +0800
testcommit-msg hook
...... 두 번째 commit에 변경 - ID가 없는 것을 발견했습니다. 이 commit에 코드를 reset하고 amend를 실행합니다.
$ git reset 1a9096a34322885ac101175ddcac7dab4c52665d
$ git commit --amend주: 위의git reset 사용법은 당신이 쓴 코드를 파괴하지 않으니 안심하고 실행하면 됩니다.이때git log에서 이commit이change-Id를 완성한 것을 발견할 수 있습니다. 다음은git reset에서 취소한 코드를 다시commit하고push를 하면 됩니다.
$ git add ......
$ git commit -m " "
$ git push review HEAD:refs/for/master방법3: 인터랙티브rebase를 사용하여 임의로 제출한 위치의Change-ID를 찾습니다.
앞의 방법2에서 제시한 예는 두 번째 제출 부족 Change-ID입니다. 이때git reset으로 문제를 해결할 수 있습니다.그러나 만약에 한 방안에서 한 달을 일하고 100개의 로컬 commit을 생성했다면 제출할 때 git log의 99번째 commit에 변경 - ID가 부족한 것을 발견할 수 있습니다. 만약 이때git reset으로 변경 - ID를 찾을 수 있다면...표고버섯은 필요 없고, 푸르고 마른 것은 필요 없다.문예 청년들은 우아하게 문제를 해결할 수 있는 방법이 있다고 말했다. 그것이 바로 상호작용식rebase이다.
첫 번째, 변경 - ID가 없는 그commit을 찾습니다.
$ git log
commit 8aaaa749db4a5b105aa746659c5cd266ac82fffe
Author: liux
Date: Mon Dec 19 17:43:24 2016 +0800
I am commit message 3
Change-Id: Ic89d5ce6ce4de70d1dcb315ce543c86a2b3ac003
commit 8e1cad33bcd98e175cba710b1eacfd631a5dda41
Author: liux
Date: Mon Dec 19 17:43:00 2016 +0800
I am commit message 2
Change-Id: I9d2af0cc31423cf808cd235de0ad02abf451937d
commit 1a9096a34322885ac101175ddcac7dab4c52665d
Author: liux
Date: Mon Dec 19 15:23:36 2016 +0800
I am commit message 1
commit d714bcde0c14ba4622d28952c4b2a80882b19927
Author: shangsb
Date: Wed Dec 14 09:20:52 2016 +0800
Change-Id: I629b2bedff95491875f63634ad3da199612735b6
...... "I am commit message 1"이 (가) 제출되었는지 변경 - ID가 없습니다.
두 번째 단계에서는 대화식 Rebase의 명령 파일을 편집합니다.
실행
git rebase -i, 인자는 이 제출한 지난번 제출한commit-id (이 예는 '폼' 제출) 입니다.$ git rebase -i d714bcde0c14ba4622d28952c4b2a80882b19927
, vi. :
pick 1a9096a I am commit message 1
pick 8e1cad3 I am commit message 2
pick 8aaaa74 I am commit message 3
# Rebase d714bcd..8aaaa74 onto d714bcd
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out이 파일을git rebase의 내장 스크립트로 이해할 수 있습니다.그 명령 쓰기 방법은 이미 아래의 주석에서 제시하였다.이 슬라이드에서는 파일을 편집할 최종 방법만 설명합니다.
reword 1a9096a I am commit message 1
pick 8e1cad3 I am commit message 2
pick 8aaaa74 I am commit message 3
# Rebase d714bcd..8aaaa74 onto d714bcd
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out즉, Change-ID가 없는 commit 앞의
pick를 reword로 바꾸면 된다(약자r도 된다).종료 저장 ((:wq 주1: 상기 파일에서commit의 순서는git log가 표시하는 순서와 상반됩니다:git log는 가장 최근입니다.상술한 문서는 최신이다.주2: 만약에 이 모드에 들어간 후에 어떻게 고쳐야 할지 확실하지 않으면 걱정하지 마세요. 편집에서 직접 물러나면 아무 일도 일어나지 않습니다(:q!)주3: 원리를 분명히 알지 못하면 필요에 따라 pick를 reword로 바꾸는 것 외에 다른 변동을 하지 않도록 주의해야 한다.특히 어떤 줄도 삭제하지 않도록 주의하십시오. (삭제된 줄에 대응하는 제출은 잃어버립니다.)주4: 여러 개의commit가Change-id가 부족한 경우도 이 방법으로 한꺼번에 처리할 수 있음을 이미 발견했을 것이다.세 번째 단계,commit-msg:
이전에 열린 파일을 저장하고 종료하면git는reword가 표시된 제출 로그 페이지를 하나씩 엽니다.아무것도 수정할 필요가 없습니다. 하나씩 저장하고 종료하면 됩니다.
4단계, 다시 제출:
git log로 제출 로그를 보면 부족한 변경 - ID가 생성된 것을 발견할 수 있습니다.즐겁게 코드를 제출하세요!
$ git push review HEAD:refs/for/master심법:
gerrit의 Change-ID 메커니즘:
우선Change-ID는gerrit(코드 심사 플랫폼)의 개념이고git(버전 관리)와는 관계가 없다는 것을 명확히 해야 한다.간단하게 말하면 Change-ID는gerrit가 구체적인 제출을 추적하는 메커니즘이다.여기에 인터넷에 이미 있는 설명을 붙이지 않고 밤 두 개를 들면 여러분은 다음과 같이 느낄 수 있습니다.
Change-ID의 생성 메커니즘은 계속 아래를 보십시오.
git의 hook 메커니즘:
갈고리(hooks)는 $GIT-DIR/hooks 디렉터리에 있는 스크립트로 특정한 이벤트(certain points)가 터치된 후에 호출됩니다.git init 명령이 호출되면, 아주 유용한 예시 갈고리 스크립트가 새 창고의 훅스 디렉터리에 복사됩니다.그러나 기본적으로 그것들은 효력이 발생하지 않는다.이 갈고리 파일의 '.sample' 파일 이름 접미사를 제거하면 효과가 발생합니다.hook 메커니즘은 리셋으로 이해할 수 있다.각 갈고리는 사실 bash 스크립트이고, 각 갈고리 스크립트의 이름은 모두 고정되어 있다.git 프로젝트 루트 디렉터리에서 볼 수 있습니다.git/hooks 이 폴더에 사용할 수 있는 갈고리가 있는지 보십시오.
$ cdproject_dir
$ ls .git/hooks/
applypatch-msg.sample commit-msg.sample pre-applypatch.sample prepare-commit-msg.sample pre-rebase.sample
commit-msg post-update.sample pre-commit.sample pre-push.sample update.sample만약 자신이 흥미를 가진git 사건을 처리해야 한다면 상응하는 갈고리 스크립트를 수정하여 편집하면 된다.그리고Sample 접미사를 제거하면 갈고리가 효력이 발생합니다.gerrit의Change-ID 생성 메커니즘에서 사실gerrit는commit-msg의 갈고리를 이용하여 우리가 코드를 제출한 후에 일정한 규칙에 따라 우리의 제출 로그를 수정하고 그 끝에 이런 줄을 추가했다.
Change-Id: .......이 갈고리 스크립트는 언제 저희 프로젝트에 들어왔을까요?사실은git push에서 오류가 발생했을 때gerrit 사이트에서 제시한 힌트 중의 명령입니다.
$ gitdir=$(git rev-parse --git-dir);scp -p -P 29418 [email protected]:hooks/commit-msg${gitdir}/hooks/이 명령을 실행하면 변경 - ID를 생성하는 갈고리 스크립트를 얻을 수 있습니다.이 명령은 다음과 같은 일을 했다.
// git rev-parse --git-dir git , gitdir .
// .git/ .
$ gitdir=$(git rev-parse --git-dir)
// scp , gerrit commit-msg ( .git/hooks/)
$ scp -p -P 29418 [email protected]:hooks/commit-msg ${gitdir}/hooks/이 스크립트를 보면 awk 명령으로 처리된 것을 알 수 있습니다.git/COMMIT_EDITMSG 파일.따라서 수동으로 Change-ID를 생성하려면 다음 명령을 실행하면 사용할 수 있는 Change-ID를 생성할 수 있습니다.
$ cdproject_dir
$ echo "some commit" > /tmp/test_generate_change_id
$ .git/hooks/commit-msg/tmp/test_generate_change_id
$ cat /tmp/test_generate_change_id
some commit
Change-Id: Ic89d5ce6ce4de70d1dcb315ce543c86a2b3ac003git commit --amend를 사용하여 Change-ID를 재생성하는 방법:
git commit --amend, 이름만 봐도 알 수 있는 어떤 commit에 대한 수정입니다.이런 수정은 파일 수정을 포함할 수도 있고 제출 로그 수정만 포함할 수도 있다.우리가--amend로commit을 수정한 후에commit-msg의 갈고리가 다시 터치되고Change-ID가 생성됩니다.대화식git rebase로 Change-ID를 생성하는 것도 마찬가지입니다.또한: 여러 차례의 Change-id 결여 사례를 정리한 결과, 기본적으로 우리가 git commit을 통해 생성한 제출은 모두 순조롭게 Change-id를 생성하는 것을 발견했다. git merge,git revert 등 명령을 통해git 자신이 생성한commit는 비교적 높은 확률로 Change-id를 결여할 수 있다. 응, 우리는 위대한 법칙을 발견했다!나란히 알을 낳다.이 문제를 어떻게 해결해야 할지 모르겠다.따라서 가능한 git rebase를 git merge 대신 사용해서 코드를 업데이트하는 것을 제창한다.사실git rebase 업데이트 코드는git merge 업데이트 코드에 비해 많은 장점이 있지만 약간 복잡할 뿐이다.코드를 git rebase 방식으로 업데이트하는 것을 강력히 권장합니다.
git rebase -i:
으윽..스스로 문서를 찾아보아라, 이것을 분명히 말하려면 또 한 무더기의 물건을 써야 한다.
좋은 웹페이지 즐겨찾기
