이번 시간에는 프로젝트 개발에서 앞서서 git 브랜치 전략을 정하는 시간을 가졌습니다.
git branch 전략이란?
git branch 전략은 프로젝트의 개발 진행 흐름을 효과적으로 관리하기 위한 work-flow입니다. 사실 서비스를 하나의 브랜치에서 작업을 하고 배포를 진행해도 되지만 여기서 발생할 수 있는 문제점은 여러가지가 있습니다.
- 여러 개발자가 동시에 작업을 하는 경우에 하나의 브랜치에서 작업을 하면 코드의 충돌이 발생할 수 있습니다.
- 하나의 브랜치로 관리를 하다가 문제가 발생하여 이전 버전으로 돌아가는 경우에 롤백 해야합니다. 즉, 현재 배포된 기능이 롤백을 해야하는 상황도 발생할 수 있습니다.
- 하나의 브랜치로 프로젝트를 관리하는 것에 가장 큰 문제점은 그 브랜치에 문제가 발생하면 개발을 하지 못할 뿐만 아니라 서비스가 운용될 수가 없습니다.
이와 같은 문제점을 방지하기 위해 개발과 배포, 오류 수정과 같은 브랜치를 나누어서 관리를 하는 것은 중요한 사항입니다. 주로 널리 이용되는 git branch 전략인 Git flow, Github flow, Gitlab flow에 대해서 알아보았습니다.
Git Flow 전략
git flow는 master, hotfix, release, develop, feature 브랜치를 가지고 개발 흐름을 관리하는 방법입니다.
각 브랜치의 역할에 대해서 알아보겠습니다.
- master 브랜치
master 브랜치는 실제 서비스에 배포된 환경을 가지고 있는 브랜치입니다. release 브랜치에 내용이 master 브랜치로 머지이 됩니다.
- hotfix 브랜치
hotfix 브랜치는 배포된 서비스에서 발생한 문제를 관리하는 브랜치입니다. 이는 release 브랜치에서 테스트할 때 발견되지 않은 오류로 급하게 수정해야할 때 이용합니다.
- release 브랜치
release 브랜치는 배포된 환경과 비슷한 개발서버에서 QA 테스트를 진행하는데 이용되는 브랜치입니다. QA 테스트를 진행하면서 발생한 오류를 수정하고 더 이상 테스트를 통해 오류가 발견되지 않으면 변경사항을 develop 브랜치와 master 브랜치로 머지합니다.
- develop 브랜치
develop 브랜치는 개발의 전반적인 내용을 관리하는 브랜치입니다. develop 브랜치에서 직접 개발을 하는 것이 아닌 각 기능들은 feature 브랜치를 만들어서 여러 개발자가 독립적으로 기능을 개발합니다.
- feature 브랜치
feature 브랜치는 하나의 기능을 개발하는 가장작은 단위의 브랜치입니다. 브랜치에 해당하는 기능 개발이 완료되면 develop 브랜치로 머지되고 삭제됩니다.
git flow를 찾아보고서 느낀 점은 git flow는 체계적으로 개발과 배포가 명확하게 분리되어서 프로젝트를 관리한다는 것이었습니다. 그래서 이는 작은 프로젝트보다는 보다 규모가 큰 프로젝트에 적용하는 것이 좋다고 느껴졌습니다.
Github Flow 전략
github flow는 git flow에서 간결해진 브랜치 전략으로 git flow와 다르게 배포 브랜치와 개발 브랜치를 나누지 않는다는 특징이 있습니다.
github flow의 흐름은 다음과 같다.
- 개발은 master 브랜치에서 시작이 된다.
- 구현할 기능이나 버그가 발생하면 새로운 브랜치를 만들어서 관리한다.
- 추가한 기능이나 수정한 버그가 올바르게 동작하면 master 브랜치에 반영한다.
확실이 github flow보다 간결하게 느껴져서 현재 서버에 프로덕트가 배포가 되지 않는 상황에서는 git flow보다 매력적인 전략입니다. 하지만 배포환경 코드와 개발환경 코드가 분리가 안되어 있어서 자잘한 버그를 잡는 것이 중요할 것 같습니다.
gitLab Flow 전략
github flow가 간단한 만큼 배포나 릴리즈에서 이슈들이 많이 발생하게 되는데 이를 보완하기 위해 나온 전략입니다. 큰 특징은 github flow와 유사하지만 개발 브랜치(master 브랜치)와 배포 브래치(production 브랜치)를 분리한 것입니다.
gitLab flow의 흐름은 다음과 같습니다.
- feature 브랜치를 에서 기능 구현을 합니다. feature 브랜치는 master 브랜치로부터 생성됩니다.
- master 브랜치에서는 feature 브랜치로부터 개발된 기능을 테스트합니다.
- 테스트의 오류가 없다면 배포 브랜치인 production 브랜치로 머지하여 서버에 배포합니다. (다만 배포환경과 비슷한 개발 서버가 존재한다면 pre-production 브랜치에 머지를 하여 테스트를 거친후 production 브랜치로 머지됩니다.)
그래서 S-HOOK의 브랜치 전략은?
위의 3가지의 널리 사용된 git branch 전략에 대해 알아보면서 팀원 모두가 의견을 냈던 부분은 개발 브랜치와 배포 브랜치를 분리를 하자는 것이었습니다. 아무래도 우테코 Level2 마지막 미션 중 배포 후 프론트와 백엔드 연동하는 과정에서 로컬환경에서는 잘 동작한 기능들이 ec2서버로 올리면 올바르게 동작하지 않는 상황이 자주 발생했어서 이와 같은 의견들이 많이 나왔던 것 같습니다.
더불어 기능 개발 브랜치와 버그 수정 브랜치를 분리하자는 의견이 추가로 나왔습니다. 이를 기반으로 앞서 살펴본 git branch 전략을 다시 보았을 때 가장 가까운 것이 git flow 방식이었습니다. 하지만 저희는 현재 개발서버가 따로 구축되어 있는 것이 아니어서 release 브랜치를 따로 구성하지 않기로 했습니다. 다만 추후에 개발 서버가 구축이 되는 경우에는 release를 브랜치를 추가하는 방안으로 결정을 내렸습니다.
이를 바탕으로 정리한 브랜치 전략을 다음과 같습니다.
- 개발 브랜치와 배포 브랜치는 분리하자
- 기능 개발 브랜치 명과 버그 수정 브래친 명은 구분하자
- 개발서버가 현재 구축되어 있으니 release 브랜치는 따로 두지 말자
래퍼런스
https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/
https://blog.hwahae.co.kr/all/tech/9507
https://nvie.com/posts/a-successful-git-branching-model/
https://vero.wiki/
