Git branch ( 깃 브랜치 ) 전략을 사용해보기로 했다.

“Github branch” 어떻게 사용하고 계신가요?

Github branch 전략에 대해 알고 계신가요?

 

저희 개발팀은 프로젝트를 개발할 때 기능별로 브랜치를 생성하거나,

dev 브랜치를 생성해서 곧바로 master 브랜치에 올리곤 했습니다.

 

프로젝트 단위가 크지 않고 프로젝트에 들어가는 개발자의 수가 많지 않았기 때문에 큰 문제는 보이지 않았습니다.

 

하지만 프로젝트에 들어가는 개발자의 수가 많아지면 많아질수록

브랜치 관리가 제대로 이루어지지 않아 수많은 브랜치가 존재했고 잦은 conflict 가 발생했으며,

master 브랜치에 곧바로 커밋 푸쉬를 진행하는 상황까지 발생했습니다.

 

당연히 문제가 발생했고 커밋 푸쉬를 하기 전 해당 프로젝트에 참여한 모든 개발자분에게

“이거 지금 마스터에 푸쉬해도 되나요?” 라고 물어보는 상황까지 오게 되었고

 

“지금 우리가 진행하는 방식은 많은 불편을 가져오고 있다.” 라고 생각하게 되었습니다.

 

이 문제를 어떤 방법으로 해결할 수 있을까?

어떻게 이 문제를 해결할 수 있을지 찾아보다 Github branch 전략에 관한 글을 찾아보게 되었습니다.

그리고 찾아본 결과 이미 많은분들이 사용중이셨고,

자세하게 해당 부분을 설명해주는 글도 찾을 수 있었습니다.

 

제가 이해한 내용은 아래의 정리한 내용과 같습니다.

---

1. Git flow

 

 

master ( 제품 배포 브랜치 )

• master 브랜치로 커밋시 태그를 사용해서 릴리즈 버전 표시

develop ( 개발자들의 작업 내용이 병합되는 브랜치 )

• master 브랜치에서 분기
• develop 브랜치에서도 모든 기능이 정상적으로 작동해야함
• 모든 기능이 추가되고, 버그가 수정되어서 배포가 가능하다면 release에 병합

release ( 제품 배포 전 QA / QC 가 진행되는 브랜치 )

• develop 브랜치에서 분기
• 버그 수정 / 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 작동하는지 확인
• 다음 릴리즈 버전을 위한 개발 작업은 develop 브랜치 에서 작업
• 배포 가능한 상태가 되면 master 브랜치로 병합 ( 릴리즈 번호 태그 추가 )
• 배포 완료후 변경하상 적용을 위해 develop 브랜치에도 병합

feature ( 단위별 기능 개발시 사용되는 브랜치 )

• 새로운 기능, 버그수정이 필요할때마다 develop에서 분기
• 개발 완료시 develop 브랜치로 병합
• 개발이 끝난 feature 브랜치는 삭제

hotfix ( 긴급 버그사항을 수정하는 브랜치 )

• master 브랜치에서 분기
• 작업후 master, develop 브랜치로 병합

---

2. Github flow

Git flow 전략이 너무 복잡해서 간략하게 만들어진 전략

 

• master 브랜치는 언제든 배포가 가능함
• master 브랜치가 항상 최신 상태 ( product에 배포되는 브런치 )
• 병합하기 전 Jenkins로 충분히 테스트 해야함
• 브랜치 이름을 명확하게 작성해야함
• 병합할 준비가 다 되었을때 풀 리퀘스트를 생성함
• master로 병합시 자동으로 배포되도록 CI 설정

개발자가 코드 작성 후 이루어지는 일

1. 풀 리퀘스트가 생성되면 mater 브랜치로 반영을 요구
2. master 권한이 있는 개발자가 풀 리퀘스트 확인, 코드 리뷰
3. master 브랜치로 반영 → CI → 배포

---

3. Gitlab flow

Github flow + Git flow

 

• production 브랜치는 특정 권한을 가진 인원만 push 가능
• production 브랜치가 항상 최신 버전을 유지하지 않아도 됨
• Git flow master == Gitlab flow production 처럼 작동
• 필요시 pre-production 브랜치로 배포전 테스트
• 병합할 준비가 되면 풀 리퀘스트 생성

 

개발자가 코드 작성 후 이루어지는 일

1. A 개발자가 새로운 브랜치 생성, 코드작업 후 커밋, 푸쉬
2. A 개발자가 기능 작업 완료 후 master 브랜치로 병합 하고 싶다면 풀 리퀘스트 생성
3. 프로젝트의 master 병합 권한자와 A 개발자가 코드 리뷰 → master 브랜치로 병합
4. 테스트가 필요한 경우 master → pre-production → production 단계로 병합

 

---

 

이제 무엇을 선택할 것인가?

 

가장 체계적이라고 생각한 것은 Git flow 였습니다.

 

Git flow 방식을 사용하면 상당히 체계적으로 작업을 할 수 있고,

여러 상황에 대응할 수 있을 것 같아 보였습니다.

 

하지만 현재 저희 개발팀은 한 프로젝트에 그렇게까지 많은 인원은 들어가지 않기 때문에

“조금 복잡한데… 조금 더 간단하게 가는 게 좋지 않을까요?” 라는 이야기가 나왔습니다.

 

그리고 저희는 사용자가 볼 수 있는 서버, 정확하게 한 번 더 체크할 수 있도록 개발 서버를 관리하고 싶었습니다.

 

위와 같은 상황을 두고 Git branch 전략을 살펴보니 아래와 같은 이유로

저희는 Gitlab flow 전략이 가장 잘 맞는다고 생각했습니다.

 

1. pre-production 브랜치를 개발 서버로 관리 가능
2. 적은 양의 브랜치로 프로젝트 관리가 가능
3. 프로젝트의 메인 개발자만 master 브랜치에 푸쉬할 수 있도록 관리

 

조금 더 우리 팀 상황에 맞춰서 사용하는 방법은?

저희는 Git flow 전략의 hotfix 브랜치가 너무나 마음에 들었습니다.

 

많은 테스트 과정과 QA / QC 과정을 거치고 프로젝트가 출시되었다고 하더라도

언젠가 어떤 이유로 버그는 발생할 수 있다고 생각했습니다.

 

어떤 버그이든지, 버그가 발생하면 발 빠르게 대응해서 고쳐야 하는 게 당연합니다.

 

회의 후, 저희는 “Gitlab flow 전략에서 hotfix 브랜치를 추가해서 사용하자” 라는 결과에 도달했습니다.

 

저희 개발팀은 프로젝트에서 어떤 버그가 발생했고, 무엇 때문에 해당 버그가 발생했는지,

다음 릴리즈에서 해당 버그를 없게 하려면 어떻게 해야하는지를 파악하는것이 중요하다고 생각했고

회의 후, 저희는 “Gitlab flow 전략에서 hotfix 브랜치를 추가해서 사용하자” 라는 결과에 도달했습니다.

 

그 이유는 이미 배포되어 있는 프로젝트에서 버그가 생기면 당장 사용자들이 사용하는 과정에서

불편함이 발생하고, 심각한 버그라면 상당히 큰 문제가 생길수도 있기 때문입니다.

 

사용 방법은 Git flow 전략의 hotfix 브랜치 사용법과 거의 같습니다.

 

1. 버그 발생
2. production 브랜치에서 hotfix 브랜치로 분기
3. hotfix 브랜치에서 문제 해결
4. product 브랜치, master 브랜치로 풀 리퀘스트 + 병합 product 브랜치로 병합할 때 태그로 릴리즈 버전을 기록합니다.
   ( ex → 1.1ver )

 

정리하자면 저희가 사용하기로 한 전략은 아래 사진과 같습니다.

 

Git flow 의 hotfix 브랜치를 가져와서 사용해보자!

 

현재 저희는 위와 같은 전략을 사용하여 프로젝트를 진행하고 있습니다.

추후 위와 같은 전략에서 문제가 생기거나,

프로젝트의 크기가 커져 더 체계적인 방법을 사용해야 하는 상황이 온다면

 

다시 한번 회의를 거쳐서 기존 전략에서 저희 팀에 맞는 방식으로 회의를 거쳐 사용할 것 같습니다.

 

 

정보 출처 : https://nvie.com/posts/a-successful-git-branching-model/

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow