4. Git vs. Gerrit

Git 은 정말 유명한 형상 관리 툴이다. (가장 훌륭하다고도 할 수 있다)

Git을 베이스로 하는 Github 는 SW 개발자들에게는 필수 코스로 자리잡았다 (Github 는 2018년에 마이크로소프트사가 75억 달러에 인수했다)

Gerrit 도 GerritHub 가 있고 여기 역시 매우 활성화 되어있다.

얘기 하고픈건, Git 과 Gerrit 중에 어느것을 선택해야 하느냐? 이다.

요즘은 둘을 병합해서 사용하기도 한다. (사내 게릿 구축 + Github 연동)

여튼, 둘중에 하나만 사용하건, 둘다 사용하건, 의사결정을 하기 위해서는 둘의 차이를 알아야 한다.

여러 차이와 각각의 장단점이 있겠지만 각설하고, 협업의 workflow 에 대해서만 얘기하고자 한다.

Github 협업 모델

Gerrit 협업 모델

다른 저장소의 내용을 변경하고 싶은 개발자는 Gerrit 에서 clone with commit-msg hook 을 통해 저장소 복제하고, 그 복제한 저장소에 변경 내용을 적용한다.
수정사항이 리뷰 받을 준비가 되면 리뷰 reference (refs/for) 에 push 한다. (git push origin HEAD:refs/for/브랜치명
Change commit object 에서 검토자를 지정하고 리뷰를 받는다.
리뷰 받은 모든 사항이 만족되면 최종적으로 maintainer (게릿에서는 commiter 라고 부르는데, 이런 용어의 차이는 의미가 없다. 결국 그 repository 를 관리하는 최종 책임자 정도로 생각하면 된다) 가 2점을 주어 merge 할 준비가 되었음을 알린다.
개발자는 최종적으로 submit 버튼을 눌러 메인 저장소에 merge 한다.

1. 리뷰 시점의 차이

Git	Gerrit
선 수정 → 후 리뷰	선 리뷰 → 후 수정
pull requests 가 되어야지만 리뷰가 이루어짐	수정사항을 push 하는 순간부터 리뷰가 이루어짐

2. 브랜치 관리의 차이

Git	Gerrit
수정사항마다 별도의 브랜치를 생성하고 폐기	브랜치는 유지하고 Change 라는 공간을 통해서 리뷰/수정을 반복

3. 반영 주체

Git	Gerrit
maintainer	수정한 개발자(commit 의 owner) 또는 maintainer

좋고 나쁨의 문제는 아니다.

다만, 코드리뷰의 내면 철학인 “팀으로부터 가능한한 일찍 피드백을 받는다”에 조금 더 충실한게 Gerrit 모델이라고 볼 수 있다.

개인적으로는 빨리 피드백을 받아서 퇴짜를 맞거나, 싸우는게 좀 더 효율적이라고 생각한다. (경험상도 그러하다)

각 회사, 팀의 상황과 성향에 맞게 고르면 된다.

다만 어느것을 선택하더라도 , 혼자서 코딩하는 시스템은 절대로 고려해서는 안된다.

먼저 리뷰하건, 나중에 리뷰하건, 개발자 혼자만의 판단으로 코딩해서 서버에 반영하는 일만은 막도록 시스템적으로 구축되어야만 한다.

(**살인을 막기 위한 사회적 장치가 필요하듯이, 오류를 막기위한 시스템적인 장치가 반드시 필요하다**)

실짱네 - 공부하고 기록하는 개발자