[Git] 프로젝트 git flow 전략

학부생, 대외활동 등을 통해 진행하던 프로젝트는 단순히 2~3명 정도가 같이 소스 코드를 관리 했기 때문에 단순히 해당 글[1]을 한번 읽어보고 우리 팀에 맞는 기초적인 방법으로 관리를 하였다.

 

그러나 현재 회사에서 진행중인 프로젝트는 약 50명 이상이 하나의 gitlab을 사용하고 각 파일들을 관리한다.

 

많은 사람들이 개발하고 운영해야 하는 git flow 전략은 어떻게 진행될까?

 

이를 어떻게 관리하는지 신입으로써, 직접 배운 내용을 정리해보았다. 

 

그림으로 한 눈에 보면 다음과 같이 정리할 수 있다.

개발을 하기전 먼저 intellij와 jira를 연동해야 한다. 과정[2]은 다음 글에 작성되어 있다.

 

[1] jira에서 이슈가 발행되어, 해당 이슈를 feature 브랜치로 만든다. 사용할 브랜치는 develop 에서 가져온다.

(단 develop 브랜치를 먼저 최신화 한다.)

[2] 작업이 완료되면 다시 develop 브랜치를 최신화 한다. 그리고 최신 develop 브랜치를 feature 브랜치로 Merge 한다.

(충돌이 날 경우 충돌을 내가 만든 브랜치에서 해결하기 위함, 이를 통해 최신 소스와 내가 만든 작업을 쉽게 동기화 할 수 있다.)

 

[3] 원격 브랜치에 push 한다. develop 에 즉시 반영되어야 할 경우 권한을 가진 관리자에게 MR을 요청한다.

(관리자는 코드와 기능을 확인 후 Merge한다. + 단순 작업이 아닌 중요한 기능 구현일시, 코드 리뷰 권장)

 

[4] develop -> release , release -> main 에 대한 Merge Request(이하 MR) 과정은 같다.

(바뀌는게 없으니 검증 서버에서 검증이 끝나면 운영 서버에 배포할지 말지 결정하는 단계)

 

[5] HotFix 발생시 main 에서 바로 feature branch 생성한다.

      작업이 완료되면 바로 origin main에 push 한다.

 

[6] HotFix 이후 develop 과 main 소스 코드가 맞지 않기 때문에 main -> release , release -> develop 역으로 Merge 한다.

 (HotFix 패치 동안 각 이전 브랜치에서 상위 브랜치(release, main)로 MR이 날라올 수도 있는데 병합하지 않고 먼저 역 Merge가 먼저이다. 충돌 방지를 위함)

 

[7] 주기적(예: 1주일에 1번)으로 main -> develop/main 브랜치에 Merge를 한다.

(Backup기능도 되고, 최신 혹은 이전 버전의 main 소스를 pull 받아 local에서 테스트 할 수 있으며, develop 작업이 main에 오랫동안 Merge되지 않을 때, 개발 분기가 길어질 수 있으므로 이를 최소화 하기 위함이다.)

 

이 외에도 다양한 방법과 규칙들이 있는데 필요한 내용일 경우 추가로 작성하겠다.

---

[1] https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

 

[2] https://jojoldu.tistory.com/260

IntelliJ를 JIRA와 연동해서 사용하기