[Gerrit] Code Review System

코드 리뷰, 하면 좋다는 건 대부분 동의할 것 같다. 그런데, 어떤 시스템을 써야 할지, 코드 리뷰에서 오버헤드가 많아지지는 않을지 걱정도 있다. 더욱이, 게시판이나 이메일, 혹은 비효율적인 시스템을 이용해서 리뷰를 해 본 적이 있다면, 리뷰 과정의 오버헤드때문에 괴로워 하기도 했을 것 같다.

만일, Git을 버전 관리 시스템으로 쓰고 있다면?

Gerrit이라는 코드 리뷰 시스템이 있다. 구글의 안드로이드 코드 리뷰도 이 Gerrit으로 진행하고 있고, 현재 일하는 회사에서도 리뷰 시스템으로 Gerrit을 쓰고 있다.


http://code.google.com/p/gerrit/


리뷰어(reviewer), 서미터(submitter)를 등록하고 리뷰를 통해 +, - 점수를 매기고 코멘트를 주고 받으면서 리뷰를 진행한다. 리뷰 과정에서 코드 수정을 자유롭게 할 수 있다. 리뷰가 완료되고 서미터에 의해 approve가 되면 해당 브랜치로 merge를 하게 된다.

이런 과정에 대해 http://source.android.com/source/life-of-a-patch.html 에서 좀 더 자세히 설명하고 있다.


Gerrit은 리뷰로 인한 오버헤드가 매우 적고, Git과도 매우 잘 통합되어 있어 Git을 쓰는 경우에는 최적의 리뷰 시스템이 아닐까 생각한다.

[Git] bundle 사용하기

git 사용 중에 push/pull 하기는 좀 어렵고 patch는 patch대로 또 좀 귀찮은 면이 있어서, push/pull 처럼 쓸 수 있는 다른 방법을 알아보니 (역시나) bundle이란 게 있다. hg 쓸때 종종 쓰던건데, 간단히 설명하자고 하면 특정 커밋(들)만 파일로 뽑아내서 저장소처럼 쓰는 방법이다.

사용법은 git bundle --help

참고자료 http://progit.org/2010/03/10/bundles.html

간단히 사용법을 정리하면,

mybranch의 커밋들 중 master에 없는 것들을 ~/mybundle 파일로 저장.

$ git bundle create ~/mybundle master..mybranch

다른 저장소에서 저걸 가져오려면, 예의상 먼저

$ git bundle verify ~/mybundle

로 검사부터 해 주고.

가져오는 방법은 다양하게 할 수 있다.

이렇게 바로 git pull 할 수도 있지만...

$ git pull ~/mybundle

이렇게 fetch + cherry-pick 할 수도 있고...

 $ git fetch ~/mybundle

$ git cherry-pick FETCH_HEAD

아니면 이렇게 fetch + rebase도 된다. (커밋이 여러개이고, 가져오는 저장소의 히스토리와 일렬로 늘어놓고 싶다면)

$ git fetch ~/mybundle

$ git rebase HEAD FETCH_HEAD

fetch 할때 브랜치 이름을 지정할 수도 있다.

$ git fetch ~/mybundle mybranch:mybranch_from_bundle

원격 저장소를 공유하지 않는 상태에서 이렇게 번들 파일을 주고 받으면서 공유할 수도 있고, 원격 저장소로의 push가 엄격히 제한이 되어 있어 push 하기는 곤란한 경우 다른 로컬 저장소에 적용해서 테스트 해 보려면 이렇게 번들을 쓰면 편하다. rebase, cherry-pick도 사용가능하니 여러 커밋들을 선택적으로 추출하거나 base가 달라 rebase를 해야 하는 경우 등에서도 patch file에 비해 훨씬 편하다.