브랜치(branch)
브랜치는 개발자들이 개발하는 공간입니다.
이 브랜치를 별도로 생성하지 않고 메인 브랜치에서만 작업을 하게 되면 어떤 일이 생길까요?
혼자 개발을 한다면 큰 문제는 생기지 않을 겁니다.
하지만 개발자라는 직업은 혼자 개발하는 것은 거의 없다고 생각하고, 협업을 통해 개발을 하기 때문에 문제가 생길 것입니다.
오직, 메인 브랜치에서만 협업을 하게 된다면 자신이 작업 중인 파일을 누군가 건드릴 수 있게 되고, 여러 기능을 개발하면서 남긴 커밋이 뒤죽박죽 섞이게 될 것입니다.
뒤죽박죽 섞인 커밋들은 개발 중인 기능이 필요가 없어지거나, 문제가 발생한다면 원하는 시점으로 롤백하기 어렵게 만듭니다.
브랜치 기능을 사용하면 다른 브랜치에 영향을 받지 않는 독립적인 환경에서 기능을 개발하거나, 버그를 수정할 수 있습니다.
쉽게 말하자면, 프로젝트 폴더를 복사해서 복사한 폴더에서 따로 작업을 하는 것입니다.
그럼으로써, 여러 기능을 여러 사람이 병렬적으로 개발할 수 있게 됩니다.
또 다른 이점으로는 기능을 개발할 때 브랜치를 생성하고 코드를 작성하여 커밋을 남기고 이 후 기능 개발이 완료된 경우에 메인 브랜치에 머지를 하면 안전하게 기능을 개발할 수 있습니다.
또한, 기능이 필요 없게 되면 간단하게 해당 브랜치를 삭제하면 끝입니다.
그리고, 실험적인 것들을 맘편하게 시도해볼 수 있고, 잘안되면 삭제하면 그만입니다.
Git 브랜치 전략
Git 브랜치 전략에서 대표적인 Git Flow, Github Flow를 살펴보겠습니다.
1. Git Flow
Git Flow는 크게 Main, Develop, Supporting 브랜치로 관리합니다.
이 때, Supporting는 또 다시 Feature, Release, Hotfix 브랜치로 나뉩니다.
Main 브랜치
출시 가능한 프로덕션 코드를 모아두는 브랜치입니다.
Main 브랜치는 프로젝트 생성 시 생기며 쭉 사용하게 됩니다.
배포된 각 버전을 Tag를 이용해 표시하기도 합니다.
Develop 브랜치
다음 버전 개발을 위한 코드를 모아두는 브랜치입니다.
개발이 완료되면 Main 브랜치로 머지합니다.
Feature 브랜치
하나의 기능을 개발하기 위한 브랜치입니다.
Develop 브랜치에서 생성하며, 기능 개발이 완료되면 Develop 브랜치로 머지합니다.
주의할 점은 Develop 브랜치로 머지하기 전에 upstream 저장소를 풀하는 것입니다.
네이밍은 feature/기능 관련 브랜치 이름과 같은 형태로 생성합니다.
Release 브랜치
소프트웨어 배포를 준비하기 위한 브랜치입니다.
버전 이름 등의 소소한 데이터를 수정하거나 배포전 사소한 버그를 수정하기 위해 사용됩니다.
Develop 브랜치에서 생성하며, 배포 준비가 완료되면 Main과 Develop 브랜치에 머지합니다.
네이밍은 release/v1.1과 같은 형태로 생성합니다.
Hotfix 브랜치
이미 배포된 버전에 문제가 발생했다면, 그 문제를 해결하기 위한 브랜치입니다.
Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 머지합니다.
네이밍은 hotfix/bug-fix과 같은 형태로 생성합니다.
2. Github Flow
Github Flow는 크게 Main, Feature 브랜치로 나뉩니다.
Main 브랜치
항상 Stable 상태여야 합니다.
즉, Main의 모든 커밋은 언제 배포하든 문제가 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 하는 것입니다.
그러므로, Main 브랜치의 모든 커밋은 빌드가 되고 테스트를 통과해야 합니다.
이것이 Github Flow가 강제하는 유일한 사항입니다.
Feature 브랜치
하나의 기능을 개발하기 위한 브랜치입니다.
Feature 브랜치이지만 목적에 따라 버그 수정을 위한 브랜치로 사용하기도 합니다.
Main 브랜치에서 생성하며, 개발이 완료 되었다면 Main 브랜치에 머지합니다.
네이밍은 목적에 따라 Git Flow 브랜치 네이밍과 동일하게 사용하면 됩니다.
어느 상황에서 어떤 브랜치 전략을 사용해야 할까?
뤼튼에 의하면...
Git Flow
- 대규모 프로젝트 또는 긴 배포 주기를 가진 프로젝트 경우
- 안정적인 프로덕션 배포와 개발 기능의 분리가 필요한 경우
- 기능 개발과 버그 수정을 명확하게 구분하여 관리하고자 할 경우
- 보안 및 긴급한 버그 수정에 대한 빠른 대응이 필요한 경우
GitHub Flow
- 작은 규모의 프로젝트나 빠른 배포 주기를 가진 프로젝트 경우
- 간단하고 직관적인 브랜치 전략을 선호하는 경우
- 실시간 협업과 지속적인 통합이 중요한 경우
- 개발자들이 자유롭게 작업할 수 있는 환경을 원할 경우
프로젝트 규모, 배포 주기, 팀의 작업 스타일, 협업 요구사항 등을 고려해서 적합한 전략을 선택해야 합니다.
마치며...
둘 다 사용해보고 각각의 장단점을 느껴봐야 이 프로젝트가 어떤 브랜치 전략이 적합할지 감이 올 것 같습니다.
개인적인 생각으로는 CI가 제대로 되어있고 적합한 머지 규칙을 정한다면 Github Flow가 더 선호되지 않을까 싶습니다.