Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

C. rework, inline source edit

Rework case 1  : 수정 요청만 받았을 떄

  • 리뷰 결과, 머지 될 수 없는 사유가 있어, 수정요청을 받았습니다. (-2를 받고야 말았습니다)
  • 이 때는 수정 요청 사항을 수정한 후, 다시 리뷰 요청을 하면 되는 데, 
  • 주의할 점은 새로 commit 하지 않고, 기존 commit을 amend option을 주어 수정 커밋 및 리뷰요청을 해야 한다는 점입니다. 새로 commit을 하게 되면, 기존 commit 내용과 별도의 리뷰 요청이 된다는 점을 주의해야 합니다.
  • 새로 커밋을 하게 된 경우  - 새로운 리뷰 건으로 올라오게 되고, git log로 확인해보아도 새로운 change ID가 생성된 것을 알 수 있습니다.

$ vi rework.txt : rework 요청된 작업을 수행
$ git add *
$ git commit -m "rework complete" : 신규로 커밋을 하게 된 경우
$ git push origin HEAD:refs/for/master : rework된 결과를 리뷰 요청

  • 그래서 반드시 리뷰 수정 사항이 생겼을 때는 git commit --amend로 작성해야 합니다.

$ 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

인라인 소스코드 편집

  1. Review 작성
  2. git push origin HEAD:refs/for/master
  3. Edit 버튼
  4. 파일 클릭
  5. Inline 소스 편집
  6. Save 및 Close 버튼 클릭
  7. Publish Edit
  8. 오른쪽 상단의 Patch Sets 변경 확인
  9. Review점수 부여 및 Submit (및 Merge)
  10. 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

: gerrit download의 checkout URL을 copy & paste 한 결과
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 37e4088... new feature

$ git log -p -all : 가져온 패치셋과 현재(로컬) master 비교
$ git diff master : 현재 브랜치 내용과 master를 비교
$ cat feature_add.txt : 내용을 출력해보면, gerrit에서 수정내역이 있는 것을 알 수 있습니다.
feature added on this branch
this is edited in gerrit
$ git checkout master : 그렇다면, master로 와서, pull URL을 가져와서, 현재 작업하고 있는 내역과 merge를 수행합니다.
$ git pull ssh://admin@localhost:29418/admin-reworktest refs/changes/79/79/2
From ssh://localhost:29418/admin-reworktest

  • branch refs/changes/79/79/2 -> FETCH_HEAD
    Updating 1b88009..37e4088
    Fast-forward
    feature_add.txt | 2 ++
    1 file changed, 2 insertions(plus)
    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에서 볼 수 있습니다.
  • No labels