[Git] Gerrit을 통한 Commit 단위 코드리뷰

프로젝트를 진행하면서 Gerrit을 통한 코드리뷰를 해야하는 상황이 생겨
Gerrit이 무엇인지와 어떤식으로 활용을 해야할지 정리가 필요하다 생각해 포스팅함.

 

Gerrit이란?

게릿(Gerrit)은 무료 웹 팀 코드 협업 도구.

소프트웨어 개발자가 팀에서 웹 브라우저를 사용해 소스 코드의 다른 사람의 수정 사항을 검토하거나 변경 사항을 승인 또는 거부할 수 있음.

Gerrit은 코드 리뷰를 자동화와 동시에 강제성을 부여함으로써 기능개발을 완료한 Commit들에 대해 원격 저장소로 Push를 할 때 자동으로 지정된 리뷰어에게 알림이 전송되며, 리뷰어는 웹 브라우저를 통해 리뷰를 진행함.

이 때 코드 리뷰를 통해 부여된 점수가 일정 수준 이상이 될 때 실제 소스코드에 반영이 이루어짐.

 

 

---

Feature

Gerrit은 Github와 비교하여 다양한 차이점이 존재함.

1. Commit 단위의 코드 리뷰가 가능. (아래에서 자세하게 기술)
2. 코드 리뷰가 권장이 아닌 필수.
3. 코드 리뷰에 점수를 부여할 수 있고, 해당 점수를 통해 실제 소스코드에 반영되거나 되지않음.

크게 3가지의 차이점이 있으며, 소규모 프로젝트에서는 대부분 Github를 통한 코드리뷰를 진행하며, 실무에서는 주로 Gerrit을 사용한다고 함.

 

 

---

Commit단위의 리뷰?

예를들어 개발자가 자신의 로컬 브랜치에서 로그인 관련 API 개발을 진행하며 ,Commit 10개에 대해 원격 저장소로 Push를 하게 되었다고 가정할 경우

 

1. Gerrit을 통해 Commit 10개에 대한 코드 리뷰가 OPEN됨.

2. OPEN된 각각의 Commit 내용에 대해 지정된 리뷰어는 리뷰를 진행하며 일정 점수를 부여.

3. 점수가 일정 기준을 만족한다면 Submit(Merge 기능)이 활성화되어 실제 소스코드에 반영시킬 수 있게 됨.

Submit 또한 각 Commit에 대해 활성화되며 개별로 반영할 수 있음.

---

그렇다면 GitHub에서 코드리뷰를 진행할 때는 어떨까?

깃헙에서 코드 리뷰 단위는 PR(Pull Request) 혹은 Gitlab의 MR(Merge Request) 단위로 진행됨.

 

즉 Commit의 개수는 상관없고, Push로 반영된 소스코드에 대해 master 브랜치 혹은 특정 브랜치로 병합(Merge)를 하기위한 요청에 대해서만 코드 리뷰를 진행할 수 있음.

 

코드 리뷰 과정에서는 승인 혹은 거부 밖에 없기 때문에 자세하게 보지 않고 승인을 하는 경우도 종종 있음.

 

 

---

깃헙, 깃랩과의 동기화(Replication)

기존 GitHub 혹은 Gitlab과의 동기화는 Access Token을 통해 Mirroring할 수 있음.

1. EC2 서버의 /opt/gerrit/etc/replication.config 파일을 수정

[gerrit]
	autoReload = true
	replicateOnStartup = true
	replicatePermissions = false
[replication]
	lockErrorMaxRetries = 5
	maxRetries = 5
[remote "gerrit repository명"]
	url = GitHub 혹은 Gitlab의 프로젝트 URL
	push = +refs/heads/*:refs/heads/*
	push = +refs/tags/*:refs/tags/*
	mirror = true
	projects = GitHub 혹은 Gitlab의 프로젝트명

 

2. Gerrit -> GitHub or Gitlab으로 미러링이 이루어지기 위해 필요한 인증관련 파일 secure.config 수정

[auth] registerEmailPrivateKey << 가 있다면 삭제

[remote "Gerrit repository명"]
	username = GitHub(or Gitlab)의 Access Token name
	password = GitHub(or Gitlab)의 Access Token값

 

3. 위 2가지의 설정 파일 수정을 완료했다면 아래 명령어를 통해 Gerrit 재시작

sudo systemctl restart gerrit

 

4. 마지막으로 Gerrit 프로세스 데몬 확인을 하며 마무리

sudo systemctl status gerrit

ps -ef | grep gerrit

 

---

로컬 개발 환경 세팅

만약 GitHub 혹은 Gitlab에서 프로젝트를 진행하고 있었던 경우 로컬의 원격 저장소를 변경해야함.

 

1. 아래 명령어를 통해 현재 원격 저장소의 주소를 확인

git remote -v

2. 아래 명령어를 통해 원격 저장소의 주소 변경

git remote set-url origin "https://[Gerrit username]@[EC2 주소]:[PORT]/[project명]

 

원격 저장소의 주소를 변경하고 난 후 최초 master(or main) 브랜치를 Gerrit 원격 저장소에 Push를 해주어야 정상적으로 replication 완료가 됨.

참고로 Push한 브랜치가 원격에서 최초 생성되는 브랜치라면 해당 Push에 대해서는 리뷰 오픈이 안됨.

 

 

혹여 Mirroring관련 문제가 발생했다면 아래 세 가지를 재확인해보면 좋음.

1. 설정 파일 작성이 잘 못되진 않았는지

2. GitHub(or Gitlab)의 Access Token 사용여부

3. master(or main)이 아닌 다른 브랜치를 Push하진 않았는지

 

 

추가로 GitHub(or Gitlab)에서의 변경사항은 Gerrit으로 반영이 되지않음 >> Gerrit -> GitHub(or Gitlab) 단방향 미러링

 

 

---

코드 리뷰 진행

Push 이 후 코드 리뷰는 Gerrit 웹 브라우저로 접속 후 상단 Nav Bar의 CHANGES -> OPEN 탭을 확인하여 진행 가능.

 

1. 좌측 상단의 Reviewers를 통해 각 Commit에 대해 Comment 및 점수를 부여할 수 있음.

2. 아래 Files 탭 및 Comments 탭을 통해 변경사항 및 리뷰내역을 확인할 수 있음.

3. 특정 기준의 점수를 만족했다면 우측 상단의 Submit 버튼을 통해 소스코드 반영 가능.

 

 

 

---

Snippet

//로컬에서 브랜치 생성
git branch 새로운 브랜치명
//로컬에서 원격 브랜치로 push
git push HEAD:refs/heads/브랜치명 //최초 원격 브랜치 생성이라면
git push HEAD:refs/for/브랜치명 //기존 원격에 있던 브랜치라면