드디어 팀에 적용하게 된 Git Branch 전략과 MR(Merge Request) 코드 리뷰 도입 과정

 

 

Git Branch 전략이 필요하게 느껴진 계기 💦

 

인텔리제이에서 GitLab을 연동해서 사용 중이었으며,

개발자들이 늘어남에 따라 브랜치에 commit 하는 기록들이 쌓여 관리가 어려워졌으며, 이렇다 보니 긴급 운영 배포 건이 있을 경우 혼잡해지기 시작

 

현재 팀에서는

dev : 개발용
staging : 운영 DB를 바라보는 운영 반영 전 테스트 확인용(release 와 비슷한 용도)
prod : 배포용

 

위와 같이 목적에 맞게 해당 Branch들은 Default로 해놓고 사용 중

dev → staging → prod 로 merge 해서 올리는 방식으로 사용

 

 

예시 ❗ 

 

1. 2024년 11월 30일 운영 배포 건

2. 2024년 12월 3일 운영 배포 건

dev로 이미 위의 해당 건들이 commit & push가 되어 있는 상황...

2가지 모두가 올라가면 prod에 반영이 되면 안되는 상황에서 
1번 건만 staging에 Cherry-pick 을 통해 commit 진행 후 staging 테스트 진행 후 이상이 없으면 staging에서 prod로 merge하여 운영 배포 진행

 

 

 

Cherry-pick ❓

 

1. 특정 기능/수정만 가져오기: 다른 브랜치에 있는 특정 수정 사항(예: 버그 픽스)을 현재 브랜치에 반영하고 싶을 때

2. 긴급 수정: 프로덕션 환경에서 필요한 특정 패치만 빠르게 가져올 때

3. 테스트: 특정 커밋만 별도로 테스트하고자 할 때

 

 

하지만, Cherry-pick을 무분별하게 사용하다 보니 문제점을 마주하게 되는데...! 😥

 

1. 충돌(Conflict): dev에서 staging으로 올릴 때 staging에 이미 cherry-pick한 건이 있다면 이 건에 대한 충돌이 발생

2. 중복 적용: 동일한 커밋이 이미 병합된 상태라면, 중복 적용으로 인해 문제 발생으로 결국, 충돌까지 일어나게 되는 현상

3. 기록 관리: cherry-pick은 커밋의 복사본을 새로 생성하기 때문에, 커밋 로그가 중복으로 생성 및 복잡

 

 

이러한 문제를 더 이상 겪고 싶지 않았고 git을 최대한 전략적으로 관리해보기 위해 Git Branch 전략을 도입하기로 결정 ‼ 🤗

 

 

 

 

 

팀에 맞는 브랜치 전략 선택 고민 그리고 결정

 

팀원들과 함께 Git Branch 전략 중 어떠한 전략을 기반으로 가져올지 많은 고민을 했는데 최종적으로 Git Branch 전략을 도입하기로 했다.

dev : 개발 DB 바라보는 개발 브랜치 (배포할 것 개발)
staging : 운영 DB 바라보는 개발 브랜치
prod : 운영 브랜치 (배포 가능한 상태)
main-feature : 기능 개발 브랜치를 merge한 브랜치, dev로 merge할 브랜치
hotfix : 운영 반영된 기능 중 버그/오류 수정을 위한 브랜치 디렉토리
feature-기능명 : 신규 기능 개발을 위한 브랜치
(hotfix인 경우 디렉토리 구조, feature인 경우 기능명 –로 연결해서 브랜치 생성)

 

 

 

 

 

 

GitLab Merge Request 기반으로 한 관리 도입

 

MR단위의 코드리뷰도 함께 도입하여 진행하였고 이는 강제성 없이 자율적으로 코드리뷰를 받고 싶은 리뷰어를 지정할 수 있게끔 하였다.

대신 승인자는 본인 기준 선임으로 진행하고 운영으로 MR을 보내는 것은 팀장님을 승인자로 두고 진행.

리뷰어는 코드 리뷰를 자유롭게 진행할 수 있으며 코멘트 룰을 적용하여 코멘트를 달 수 있게끔 규칙을 만들어서 적용시켰다.

 

전반적인 흐름은 아래와 같이 진행되고 있다.

 

 

[ Merge request reviewer comment rules ]

P1: 꼭 반영해 주세요 (Request changes)

P2: 적극적으로 고려해 주세요 (Request changes)

P3: 웬만하면 반영해 주세요 (Comment)

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

P5: 그냥 사소한 의견입니다 (Approve)

 

 

 

 

 

효과 👏

 

1) 효율성

- MR 작성으로 어떠한 개발 건인지 한 눈에 확인 가능하며 관리가 용이해짐

- branch merge를 MR을 승인을 통해 가능하게함으로써 무분별한 merge 제한, merge 충돌 발생 가능성이 감소함

 

 

2) 코드 품질 향상

- MR을 통해 코드리뷰가 가능해짐으로써 버그 및 실수를 사전에 방지 할 수 있고 코드의 일관성 보장

- 서로 피드백을 해주는 과정 속에 더 나은 코드를 만들 수 있고 협업하는데 좋은 동기 부여가 생김

 

 

3) 협업 강화

- 모두가 자유롭게 리뷰를 할 수 있는 공간이 마련되면서 한 모듈만 맡아 진행하고 있던 개발자가 다른 모듈의 개발을 파악하고 이해하기 쉬워짐

- 모든 팀원이 합의된 기준과 리뷰를 거쳐 코드가 병합되므로, 코드베이스의 신뢰도와 안정성이 보장됨

 

 

 

---

느낀점 💭

 

팀원들과 회의 끝에 Git Branch 전략과 함께 MR 단위의 코드리뷰 방식을 도입하게 되면서 (도입 시점 2024년 11월 말)

스스로 발전하기에 제한적이었던 환경 내에서 협업을 통해 나아가는 계기가 되었고 한 층 더 성장할 수 있는 계기가 되었다.

아직까지는 적응하고 익숙해지느라 다소 느리지만 이 프로세스를 잘 유지 중이며,

자사 git 관련 가이드 또한 계속 develop하여 완성도 있는 가이드를 만들어 유지하는 것이 목표다 :)