(4)-5.GERRIT - B.+Review+push,+fetch,+pull

Owned by 재석 박
Last updated: 2017-08-29
3 min read

[Git & Gerrit Home으로 돌아가기]

B. Review push, fetch, pull

  • Review Push
  •  Change Screen
  • Fetch Merged commit 

Gerrit에서 성공적으로 Project을 clone받아왔습니다.
보다 실전에 가까워진듯한 느낌이 드는데요. 이번 실습에선 Gerrit의 Pending Change에  작업한 내용을 Review Push해 볼 수 있도록 하겠습니다.
Gerrit에서 Clone받은 Workspace로 이동하세요.
$ cd gerrit_test : clone 으로 받아온, gerrit 프로젝트 명과 같은 Workspace

Review Push

열일했다고 가정하고, commit을 하나 만들어 보겠습니다.

  1. mybranch 란 branch를 생성하고, branch.txt 파일을 만든 후, master에 merge (사실은 아무거나 커밋하셔도 됩니다.) 

$ git checkout -b mybranch
$ vi branch.txt
$ git add branch.txt
$ git commit -m "1st review" : 1st review란 이름으로 review 요청
$ git log
$ git checkout master
$ git merge mybranch
로그를 보면 Change-Id가 잘 생성되어 있습니다. 개발을 하다보면 몇 가지 경우에 Change-ID가 날라가는 경우가 있습니다. 이럴 경우, 해당 커밋을 버릴 수 밖에 없으니 주의하세요.  (이럴 때는 git reset HEAD~1 등으로 change ID를 잃어버린 커밋을 버리는 수 밖에 없습니다.)  Change-ID가 날라가는 경우는 해당되는 경우에 말씀드리겠습니다.

  1. 리뷰 푸시의 문법은 다음과 같습니다.

< git push origin HEAD:refs/for/(서버브랜치명) >
우리는 master branch에 push하도록 하겠습니다. 실제 어떤 branch에 push할지는 commiter(관리자)가 정해줍니다.
서버 브랜치는 admin권한으로 gerrit에서 생성할 수 있습니다.
$ git push origin HEAD:refs/for/master

  1. Gerrit의 All → Open 으로 가보면 Review Push된 Commit을 볼 수 있습니다. 만약 리뷰 푸시할 때, 커밋을 여러개 했다면, 여러개의 리뷰 푸시가 한꺼번에 올라갑니다. 중간 커밋까지 같이 리뷰를 받아야 하는 경우 또는 중간 커밋이 릴리스 후보 되는 경우가 아니라면, 최종 커밋 하나만 리뷰 푸시 할 수 있도록 해야 합니다. (리뷰 예절)

Review in Gerrit

  1. 리뷰 푸시된 커밋을 눌러보면 다음과 같은 Change Screen이 뜹니다.

 Change Screen

  • Change Screen 은 단일 커밋 내용들의 세부 사항을 표시하고 이에 대한 다양한 조치를 제공합니다.
  • Change Screen 구성 요소는 다음과 같습니다.
    1. Commit Message Block
    2. Commit Info Block
    3. Change Info Block
    4. File List
    5. Patch Sets
    6. Download
    7. Included In
    8. Star Change
    9. Related Changes
    10. Reply
    11. Changes
    12. Update Notification
    13. Plugin Extensions


Change Screen에는 무려 13가지 섹션으로 이루어져있습니다. 실제 저희가 Gerrit을 쓴다면 대부분 이 화면을 쓰게 됩니다. 자세한 설명서는 . 2-1 Gerrit UI Guide 에 있으니, 꼭 한 번 읽어보세요

  • 간단한 것부터 해보죠. 가운데를 보면, 담당자, 리뷰어를 설정할 수 있습니다. 아이콘을 누르고, ID나 이메일을 적으면 됩니다. Topic도 간단히 지정해서 관리할 수 있습니다.
  • 리뷰어를 지정해 보시고, 토픽도 정해 보세요. 상단 타이틀 바의 My → Changes 엑 가면 나에게 리뷰 오청온 항목 (Incoming Review)을 볼 수 있습니다

지금 보는 Change Screen에서 상단 왼쪽을 보면 현재 리뷰 푸시에 대한 상태가 나와 있습니다. Needs Verified Label은 빌드에 문제가 없는지, CI 서버(Quick Build, Jenkins)가 자동으로 돌아서 빌드 성공 실패를 판단해주고, Verify가 끝나야 리뷰를 할 수 있습니다.

  • CI서버에 의해 빌드가 성공하여 Verify Label에 +1을 받았다고 가정하고 리뷰를 진행해 볼께요.

 

  • 리뷰 결과, 수정 사항 없이 Merge 에 필요한 +2를 받았다고 가정하곘습니다.

 

  • All → Merged 로 이동하여 서버에서 생성한 프로젝트의 master branch에 리뷰요청한 커밋이 잘 반영된 것을 확인하세요.

 

Fetch Merged commit 

  • 개발자 PC로 와서 , Local Repository로 merge된 리뷰 커밋을 당겨와서 Review 결과를 확인하고 Pull 해서 Merge해 보도록 하겠습니다. 

$ git fetch
$ git checkout FETCH_HEAD : fetch된 결과를 확인하려면, FETCH_HEAD로 가서, diff로 확인할 수 있습니다.
$ git diff master : 리뷰 과정에서 수정된 것이 없는 것을 확인할 수 있습니다.
$ git checkout master
$ git pull : master로 돌아와서, 확인사살? (안전빵)으로 git pull 수행합니다. 한 줄의 수정도 없이, 잘 리뷰 통과 된 것을 알 수 있습니다.(yeah~~~)

  • 참고)Commit 취소

git reset --hard HEAD : 모든 변경 무시하고, 현재 버전으로 정리합니다, (staging과 working dir을 싹 비우는 것을 의미합니다.)
git reset --hard HEAD^ : 현재 버전 하나 앞으로 정리 - 최종 Commit 하나 취소 - HEAD^ = HEAD~1
git reset --hard HEAD~2 : 최종 Commit 2개(또는 N개) 취소
git reset --hard origin/master : 서버의 master 버전을 기준으로 롤백
git reset --hard 84cf88 : 특정 Commit 버전으로 롤백

참고 : git reset 의 옵션 ??? --soft , --mixed, --hard