프로그래머의 일상: git 저장소 권한 관리

지금 일하는 곳에선 linux 개발환경을 쓰고, 소스 저장소로는 git을 쓴다.  그리고 여기에 코드 리뷰 도구인 gerrit2를 이용하는데, 이 조합으로 작업하면서 느낀 점을 간단히 써본다.

git이 DVCS이긴 하지만 그래도 canonical 저장소는 있어야 한다. 근데 git 특성(?)상 권한관리의 개념이 희박하다.¹ 저장소가 전체 쓰기가 가능하거나/읽기만 가능하거나/접근할 수 없거나 정도의 권한 수준만 있다. 그래서 많은 프로젝트의 canonical git 저장소는 linux kernel처럼 hierachical하게 패치/메일로 merge하거나, github.com의 pull request처럼 한 명, 혹은 소수가 gate-keeper의 역할을 맡아서 이를 대신한다.

하지만 회사 환경에서 쓰기엔 이런 방법들은 좀 불합리(?)한 듯 싶다. 위의 방법을 써서 gate-keeper에게 부하가 걸리거나, 아니면 권한이 열려 있어서 권한 관리가 잘 안되거나일 것 같다. 그래서인지 여기서는 다음의 방법으로 권한 관리를 대체(?)한다.

• 모든 개발자는 읽기 권한만 갖는다
• 개발자들은 메인 저장소가 아닌 코드 리뷰 도구(여기서는 gerrit2)에 push한다.
• 리뷰 결과 수정할 부분은 수정하고 다시 push
• 리뷰 결과가 좋으면 gerrit2이 canonical 저장소에 commit

이러면 코드 리뷰를 통과한 것만 실제 canonical 저장소에 들어가는 식으로 권한 관리가 이루어진다.

예를 들어 나는 somelib만 관리하는데 anotherlib에 이상한 수정 사항을 넣었다 치자. 그 쪽 코드 관리하는 사람이 리뷰에서 탈락 시키는 형태로 권한 관리하면 끝이다. 코드 리뷰가 중간에 끼인 거라 당연히도 코드 리뷰의 장점도 전부 포함하게 됨.

덤으로 gerrit2설정에 따라 다르겠지만, canonical 저장소의 이력(history)을 branch가 매우 많은 DVCS 특유의 모습이 아니라, svn 이나 p4에서 흔히 볼 수 있는 선형적인 이력으로 유지할 수도 있다.

PS. git을 소스 저장소 시스템으로 사용하는게 난이도가 좀 있을지도 모른다고 생각했었다. 하지만 내가 입사한 이후에 합류한 분들이나, 여름 방학 기간 중에 인턴으로 들어오신 분들도 간단한 git 소개 페이지를 읽고 gerrit을 통해 커밋할 수 있게 되는데는 일주일 이하의 시간이 걸린 것 같다.

그러니 그런 이유로 git 저장소 도입을 망설일 필요는 없을 것 같다. gerrit2 처럼 중간에 gate-keeping하는 녀석이 있으면 실제로 삽질할 수 있는 일의 가짓수도 줄어들어서 git 에 익숙한 사용자가 한 두명 있으면 어떻게든 진행할 수 있을 것이다.