현재 프로젝트에서 브랜치 전략 개선해보기

현재 진행하고 있는 프로젝트의 브랜치 전략

- main: 제품으로 출시될 수 있는 브랜치

- dev-fe: 다음 출시 버전을 개발하는 브랜치

- feature: 기능을 개발하는 브랜치

- dev-release: 이번 출시 버전을 준비하는 브랜치

 

총 4가지의 브랜치를 운영하고 있습니다.

1. main에서 dev-fe 브랜치를 생성한다.

2. 기능 단위로 이슈를 등록 후 feature 브랜치를 생성한다.

- 2명이서 진행했기 때문에 담당자 이름 약자(ex: ayr)/feature/이슈넘버가 들어가게 브랜치 룰을 정했습니다.

3. 기능을 완성하면 feature 브랜치를 dev-fe에 merge한다.

4. dev-fe에서 pull 받아와서 제대로 작동하는지 확인 및 버그 수정을 진행한다.

5. 제대로 작동하면, dev-fe에서 dev-release 브랜치로 merge한다.

 

현재 프로젝트에서 파생된 문제점과 궁금증

1. feature 브랜치에서 dev-fe에 Pr을 보내고 merge를 하는데, merge할 때 다양한 merge 종류가 존재해서 어떤 걸로 하는게 제일 좋은 건지 궁금해져서 처음에는 Create a merge commit를 이용하다가, 후에는 Squash and merge도 해보고 Rebase and merge도 해보기는 했다. 근데 하다보니 이렇게 주구난방으로 하는 것보다 확실하게 알고, 적용을 해야겠다고 생각하게 되었다.

 

2. 처음에 dev-release를 dev-fe에서 생성한게 아니라 Github에서 직접 브랜치를 생성해주었고, 기능이 완성되면, dev-relase로 pr을 보내거나 dev-fe에서 dev-release로 push하는 방식으로 진행하였고, 배포 시 오류가 뜨면 dev-fe 오류 수정을 진행했다. 그러다보니 commit도 그냥 짬뽕 commit이 되어가고 있었다.

 

3. 이젠 프로젝트가 끝나서 dev-release에서 main으로 pr을 날려서 merge하려고 하는데 이게 맞는지 의문점도 생겼고, Git tag라는 것도 있던데 이건 왜 적용하고, 어떻게 적용하는 거지 궁금하고 한번 적용해보고 싶었다.

 

그래서 이런 저런 이유로 점점 내 프로젝트는 짬뽕이 되어가고 있는 거 같았고, 아... 브랜치 전략 좀 개선해봐야겠다고 생각을 하게 되었다. 아래 내 git log도 그냥 짬뽕 그자체다.... 

 

현재 진행하고 있는 프로젝트 브랜치 전략 개선

현재 프로젝트가 완료된 상태이다. 앞으로 진행하는 프로젝트의 경우 혼자서 코드 개선이나 사용성 개선이 주이기 때문에 버전 관리랑 git flow를 도입하는 거는 불필요하다고 생각이 들었다. Git Tag, Git Flow, 버전 관리를 도입하고 싶어서 공부를 해보았는데, 지금 프로젝트에서는 그렇게 적합하지 않는 flow였기 때문에 지금 현 상황에 맞는 브랜치 전략으로 재구성해보았다.

 

변경된 브랜치 전략

- main: CI/CD를 진행하며 제품으로 출시되는 브랜치

- dev-fe: 다음 출시 버전을 개발하며, 배포하면서 발생되는 오류를 fix한다.

- feature: 기능 개발 브랜치( 이슈 단위로 생성)

 

브랜치 병합 룰

feature -> dev-fe 

Squash and Merge를 사용한다. 커밋 히스토리를 모두 묶어서 새로운 커밋으로 추가하여 지저분한 커밋 히스토리를 개선할 수 있다.

 

dev-fe -> main

Rebase and Merge를 사용한다. develop의 내용을 master에 추가하여 별도의 새로운 커밋을 생성할 이유가 없다.

 

공부해서 정리한 글

개발 버전 관리

 

GitHub Flow와 Git Flow 중에 어떤 걸 선택해야하지?