협업을 통해 프로젝트를 진행할 때는 대부분 Git(또는 SVN)을 이용해 형상을 관리하며 사용하고 계실 겁니다.
하지만 Git에 대해 잘 모르거나 사용해보지 않으신분들은 branch를 생성하지 않고 바로 main(master) 브랜치에 커밋하고 푸시를 한 경험이 한 번 정도는 있을 것이라고 생각합니다.
이는 혼자 사용하는 레포지토리에서 연습용으로 사용하는 것이라면 괜찮겠지만,
만약 이러한 일이 여럿이서 개발하는 레포지토리에서 발생하게 된다면 어떤 일이 일어나게 될까요?
서로 다른 파일을 커밋할 때
서로 다른 파일을 커밋할 때에는 원격저장소에서 충돌되는 부분이 없기 때문에 자동으로 병합이 진행됩니다.
(같은 파일이여도 서로 다른 부분만 수정했을 경우 자동 병합 됨.)
같은 파일을 커밋할 때
하지만 같은 파일, 같은 부분을 수정하면 충돌(Conflict)이 발생하고 이를 처리해야 합니다.
만약 처리를 하지 않는다면 GitHub가 이전코드와 변경사항 중 어떤 것으로 남겨두어야 하는지 알지 못하게 됩니다.
때문에 자동으로 병합을 하지 않고 사용자에게 Conflict 메시지와 함께 충돌을 해결하기를 요구합니다.
이는 더 많은 사용자가 함께 사용하고 더 빈번하게 작업이 이루어진다면 대 충돌시대를 맞이할 수 있습니다.
그렇다면 이러한 상황이 발생하지 않도록 사전에 미리 차단하려고 하면 어떻게 할 수 있을까요?
Git Branch 전략을 사용해 보자!
Git Branch 전략이란 branch에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow를 정의하는 것을 말합니다.
쉽게 말하면 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 branch 사용 방법을 정의한 것으로 볼 수 있습니다.
Git Flow 전략
브랜치 전략 중 가장 유명하기도 하고 많은 회사와 팀에서 기본으로 사용하고 있는 것이 Git Flow 전략이라고 할 수 있을 것 같습니다.
- 5가지의 브랜치를 이용해서 저장소를 운영하는 브랜치 전략입니다.
- 이 중 2가지 브랜치는 항상 유지 되는데 Production(운영 환경) 배포 브랜치와 Develop(개발 환경) 배포 브랜치입니다.
- 나머지는 보조 브랜치로 분기하여 코드를 작성하고 merge가 되면 사라집니다.
- feature는 다음 기능을 개발하는 브랜치로 개발이 완료되면 develop 브랜치에 병합합니다.
- release는 다음 버전 출시를 준비하는 브랜치로 develop에서 release 브랜치로 옮긴 후 QA와 테스트를 진행하고 이상이 없다면 master 브랜치로 병합합니다.
- hotfix는 master 브랜치에서 발생한 버그를 빠르게 수정하기 위해 사용하는 브랜치로, master에서 분기되어 master로 병합됩니다.
Github Flow 전략
Github Flow는 GitHub에서 제안하는 프로젝트 관리방법입니다.
이는 기존의 Git flow도 좋은 방식이긴 하지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon(깃허브 창립자 중 한 명)의 판단으로 만들어진 깃 관리 방식입니다.
- release branch가 명확하게 구분되지 않은 시스템에서 사용하면 유용합니다.
- 모든 브랜치를 구분하던 사항도 결국 개발자가 전부 수정하는 일이므로 별도로 브랜치를 구분하지 않고,
- 어느 것이 우선 순위가 더 높은지에 대한 것만 구분합니다.
- 동작흐름 : 브랜치 생성 -> 커밋 -> PR 생성 -> 코드 리뷰 리뷰 리뷰 리뷰..-> 테스트 -> Master Merge
우리가 사용하는 프로젝트 브랜치 전략
우리 팀이 프로젝트에서 사용하는 전략은 Git Flow 입니다.
먼저 프로젝트의 기능 개발을 진행하는 순서를 간단하게 설명해 드리자면.
Git 기능 개발 작업 흐름
- 작업 시작 전: 작업을 시작하기 전, JIRA 티켓을 생성합니다.
- 작업 단위: 하나의 티켓은 하나의 PR이며, 최대한 작은 단위로 가져갑니다.
- PR 및 코드리뷰: PR은 꼭 코드리뷰를 진행하며, 이상이 없다면 승인(Approve)합니다.
- 정적 분석: PR이 생성된 후, 매 커밋마다 코드에 이상이 없는지 정적 분석이 진행됩니다.
- 병합: 승인된 PR은 Squash Merge방식으로 dev브랜치에 병합합니다
- 자동 배포: dev가 정상적으로 병합되고 배포된다면, prod 브랜치도 운영환경에 배포합니다.
Git Flow
prod 브랜치
- 실제 운영환경에서 사용되는 브런치입니다.
- 이 브랜치의 코드는 항상 안정적이여야 하며, 사용자에게 직접 제공되는 서비스의 코드입니다.
- dev 브랜치에서 빌드 및 테스트가 성공적으로 완료되면, GitHub Actions를 통해 prod브랜치로 배포합니다.
dev 브랜치
- 배포 준비가 된 기능들을 통합하는 브랜치입니다.
- prod브랜치로 배포되기 전에 최종 테스트를 진행하는 브랜치입니다.
- 모든 기능 개발이나 버그 수정 작업은 dev브랜치에서 분기됩니다.
feature / refactor 브랜치
- 새로운 기능 개발(feature), 코드 리팩토링(refactor)을 진행하는 브랜치입니다.
- 각 작업을 진행한 후 PR을 생성하여 코드리뷰를 요청합니다.
- 리뷰어의 승인을 받으면 Squash Merge를 통해 dev브랜치에 병합합니다.
이러한 브랜치 전략을 선택한 이유는 자유롭게 개발하여 dev에 병합하는 과정을 통해 빠르게 기능개발과 리팩토링을 진행할 수 있으며,
dev로 병합된 코드는 실제 배포환경과 비슷한 환경에서 배포하여 테스트할 수 있어 문제가 없을 시에만 prod로 배포 하여 언제나 안정적으로 서비스를 운영할 수 있습니다.
글을 마치며.
깃 브랜치 전략으로는 글에서 설명한 전략 이외에도 GitLab Flow, Release Flow 등이 존재하는데 많은 방법들이 존재하지만 대표적으로는 Git Flow 방식과 GitHub Flow만 이해하고 있어도 충분히 Git을 통해 협업하는데에는 도움을 받을 수 있을 것 같습니다.