...
...
C. rework, inline source edit
...
$ git reset HEAD~1 : reset 에 hard option 주면 workdir까지 날라갑니다.
Unstaged changes after reset:
M rework.txt
$ cat rework.txt : workdir 내용은 그대로 남아 있음.
this is for rework1
rework complete
$ git add * : 만약 reset에 soft옵션을 주었다면 스테이징도 다시 안해도 됨.
$ git commit --amend : vi로 커밋 메시지를 수정하게 됨. 이 때 commit message를 rework complete로 정함.
$ git push origin HEAD:refs/for/master
Inline Source Code Edit
인라인 소스코드 편집
- Review 작성
- git push origin HEAD:refs/for/master
- Edit 버튼
- 파일 클릭
- Inline 소스 편집
- Save 및 Close 버튼 클릭
- Publish Edit
- 오른쪽 상단의 Patch Sets 변경 확인
- Review점수 부여 및 Submit (및 Merge)
- git pull → 충돌 발생
이렇게 되기 (개발자는 자기도 모르게 코드 변경이 되어 있기 때문)때문에, review가 소스 코드를 수정하게 하더라도, 개발자에게 다시 rework 요청을 하는 것이 맞습니다.
그렇다면, 리뷰어가 소스 수정 내역이 있을 때, 개발자는 어떻게 이어서 개발하게 되는 지 다음 시나리오에서 살펴보곘습니다.
Rework case 2 : 수정된 소스와 함께 수정요청을 받았을 때
- rework요청이 왔는 데, 이번엔 소스에 대해 직접 수정된 내역이 있어서, 해당 부분을 참고해서 작업을 해야 할 때입니다.
- 리뷰어가 직접 소스를 수정하였다면, 그 내역은 어디에 있을까요?
- 지금 리뷰 중인 부분은 fetch set에 들어 있고, 을 받아오기 위해선, gerrit의 download에서 URL을 복사한 후, console에 붙여 넣기 하는 방법으로 가져옵니다.
- 먼저 fetch URL을 가져와서 검토해보고, 변경 내역이 확인되면, pull URL을 가져다가 지금 작업하고 있는 소스에 merge하겠습니다.
- $ git fetch ssh://admin@localhost:29418/admin-reworktest refs/changes/79/79/2 && git checkout FETCH_HEAD
...
- branch refs/changes/79/79/2 -> FETCH_HEAD
Updating 1b88009..37e4088
Fast-forward
feature_add.txt | 2 ++
1 file changed, 2 insertions
create mode 100644 feature_add.txt
$ cat feature_add.txt
feature added on this branch
this is edited in gerrit
$ vi feature_add.txt : 리뷰에서 요청된 수정을 완료한 이후
$ cat feature_add.txt
feature added on this branch
this is edited in gerrit
reworked complete
$ git commit --amend : amend로 commit을 수행한 다음, 리뷰 요청합니다.
$ git push origin HEAD:refs/for/master
- 커미터는 리뷰어가 요청한 수정 요청 내역을 확인하고, code review 점수에 +2를 부여하여, submit합니다.
- 여기에서 submit을 누르면, 드디어 리뷰가 완료되어, 해당 commit은 authoritative repository로 merge되고, All → Merged에서 볼 수 있습니다.