[Git] Branch 전략

Git을 이용한 Branch 전략

개발 프로세스에서 어떤 브랜치를 구성하고 관리할지에 대한 규칙과 가이드라인이다. 다수의 개발자가 협업하는 환경에서는 개발 팀의 코드에 대한 효율적인 관리와 협업을 위한 체계적인 방법이 필요한데, 이 때 여러 브랜치로 나누어 관리하는 방식이다.

 

Branch 전략의 필요성

① 병렬 개발: 여러 개발자가 동시에 여러 기능을 개발할 때 서로의 개발 작업에 끼치는 영향을 최소화할 수 있다.

② 코드 안정성: 메인 브랜치의 안정성을 유지하면서 새로운 기능을 개발할 수 있다.

③ 릴리스 관리: 특정 버전의 코드를 쉽게 관리하고 배포할 수 있다.

④ 버그 수정: 긴급한 버그 수정을 메인 개발 흐름과 분리하여 처리할 수 있다.

⑤ 실험적 기능: 리스크가 있는 새로운 기능을 안전하게 시도해볼 수 있다.

 

Branch 전략의 종류 (대표적으로 많이 사용하는 네 가지 전략)

① Git Flow

main, develop, feature, release, hotfix 5개의 브랜치를 사용하는 것을 권장하는 방식이다. 5개의 브랜치 중 main, develop 브랜치는 필수로 사용하고 나머지 3개의 브랜치는 필요에 따라 생성해서 사용한다. 특정 목적을 달성하고 난 다음에는 선택적으로 생성한 브랜치를 제거할 수도 있다. 가장 많이 사용되는 전략이지만, 전략을 잘못 사용하게 되면 브랜치가 많아지면서 코드 품질이 저하될 수 있다. 대규모 프로젝트나 정기적인 릴리즈가 있는 프로젝트에 적합하다.

 

Branch	Required	Description
main	○	• 이 브랜치에 변경 사항이 발생하는 경우 운영 환경으로 배포하는데 활용 (=서비스 버전 업)
develop	○	• 기능 개발 된 후 단위 테스트까지 마무리된 깔끔한 코드를 저장하는 브랜치 • 이 브랜치에 변경 사항이 발생하는 경우 개발 환경으로 배포하는데 활용
release	×	• develop 브랜치의 코드를 main 브랜치로 병합하기 전에 테스트 환경에 배포 테스트를 위해 사용 • 이 브랜치에서 배포 테스트가 완료된 후 이상이 없을 경우 main 브랜치로 병합
feature	×	• 신규 기능을 개발하기 위해 사용하는 브랜치 • 기능 개발이 완료되고 나면 단위 테스트까지 마무리 한 다음 develop 브랜치로 병합
hotfix	×	• 서비스 운영 중 중대한 버그가 발생해 바로 수정이 필요한 경우 활용하는 브랜치 • 버그가 개선된 코드는 main, develop 브랜치로 병합

 

② GitHub Flow

Git Flow의 복잡한 브랜치 관리 방식을 단순화한 전략으로 2개의 브랜치로 줄여서 사용하는 방식이다. Git Flow가 사용하는 release, develop, hotfix 브랜치를 모두 하나의 기능 개발로 간주하고 feature와 같은 기능 개발용 브랜치와 main 브랜치만 유지하는 전략이다. 동작 과정이 단순하기 때문에 간단하고 빠른 개발 프로젝트에 적합하다. Issue Tracking System(Jira) 에서 백로그 목록에 존재하는 개발 기능 중 하나를 선택 후 main 브랜치에서 feature 브랜치로 분기해서 기능 개발을 시작한다. 개발이 완료되면 main 브랜치로 Pull Request를 생성해 하나의 핵심 브랜치만 관리한다. 팀 리더나 리뷰어가 코드 검토 및 리뷰 후 PR이 승인되면 자동으로 CI/CD 툴에 의해 빌드 및 배포까지 이어진다.

Branch	Required	Description
main	○	• 이 브랜치에 변경 사항이 발생하는 경우 운영 환경으로 배포하는데 활용 (=서비스 버전 업) • 이 브랜치는 언제나 배포 가능한 상태로 유지 필요 • 이 브랜치에 대한 엄격한 역할 및 권한 관리가 요구됨
feature	○	• release, develop, hotfix 브랜치를 별도로 관리하지 않는다. • hotfix 조차 하나의 기능 변경 사항으로 간주 • 자유롭게 기능에 따라서 생성 및 관리

 

③ GitLab Flow

Gti Flow와 GitHub Flow의 장점을 결합한 브래친 전략이다. 기능 개발을 위해서 feature 브랜치를 이용하고, main 브랜치에서는 배포를 위한 안정적인 코드를 관리하는 역할로 사용한다. 운영 환경에 배포하기 전에 테스트를 위한 Staging 브랜치를 이용해 QA 테스트와 UAT(User Acceptance Testing)을 진행한다. Staging 브랜치에서 테스트가 종료되면 Production 브랜치를 이용해서 운영환경에 배포한다.

Branch	Required	Description
main	○	• 기능이 개발된 최종 배포 코드를 안정적으로 유지관리 하기 위한 역할
feature	○	• 신규 기능 개발에 사용하는 브랜치
staging	○	• 운영 환경 배포 전 QA와 UAT 진행에 사용되는 브랜치
production	○	• 실제 운영 환경에 배포할 때 사용되는 브랜치 (운영환경 배포 역할만 담당)

 

④ Trunk Based Development (TBD)

단일 브랜치로 구성해 코드를 관리하는 전략이다. 단일 브랜치에 직접 개발자의 코드를 병합한다. 핵심은 짧은 시간 단위로 병합이 이루어지도록 관리하는 것이다. 병합 전에는 항상 코드 리뷰를 진행하는 문화가 정착되어 있어야 하는데, 짧게는 몇 시간 길게는 하루 단위로 병합을 진행하면서 충돌이 발생하더라도 영향이 작은 코드를 주기적으로 병합하는 방식이다. 병합 후에는 자동으로 CI 시스템을 통해 빌드/테스트/통합 과정을 거치는데 문제가 없을 경우 운영환경에 배포된다.

TBD 자체가 가지고 있는 특성 때문에 반드시 선제조건이 충족된 상황에서만 사용하는 것이 좋다. 먼저, ⓐ 코드리뷰 문화가 반드시 정착되어 있어야 한다. 미팅 진행 후 병합이 이루어지기 때문이다. 그리고, ⓑ 하루 단위의 개발 분량을 쪼개서 관리할 수 있을 만큼 기능을 소규모로 작게 잘라서 관리할 수 있는 능력이 필요하다. 특히, 개발 리더에게는 더욱 이러한 역량이 필요한데 비즈니스 도메인, 개발 지식, 아키텍처 등에 대한 해박한 지식을 통해 마이크로 매니징이 가능해야 이 전략을 유지할 수 있다. ⓒ 병합 전에는 반드시 단위 테스트를 마쳐야 한다. ⓓ 병합 주기를 짧게 몇 시간 혹은 하루에 한 번 단위로 진행해야 한다. ⓔ TDD(Test Driven Development)가 도입되어야 한다. ⓕ 페어 프로그래밍이 도입되어야 한다.

 

전략 장단점

구분	장점	단점	비고
Git Flow	• 기능 단위로 독립적인 브랜치 관리 • 다른 개발 결과물에 영향 최소화 • 메인 브랜치 깔끔한 유지 • 브랜치별 CI/CD 연동에 용이함	• 개발자가 많아지면서 브랜치 관리를 잘 못할 경우 복잡해짐 • 병합 충돌 해결을 위해 사용되는 리소스가 늘어나 코드 품질 저하로 이어짐 • 코드에 대한 피드백이 느려짐	대규모 프로젝트나 정기적인 릴리스가 있는 프로젝트에 적합
GitHub Flow	• 단순하고 이해하기 쉬움 • 빠르게 개발 및 배포에 용이 • 빠른 제품 피드백이 가능	• 릴리스 단계를 관리하지 않기 때문에 대규모 프로젝트에 부적합	CI/CD 전 과정이 자동화 되어 있는 소규모 애플리케이션 개발하는 팀에서 사용하기에 적합
GitLab Flow	• 규모에 관계 없이 사용 가능 • 운영 환경에 배포되는 버전이 항상 최신 버전으로 유지될 필요가 없음	• 상대적으로 단순하지도 않고, 체계적이지도 않음	규모에 관계 없이 사용 가능
TBD	• 자주 소규모 병합을 수행하여 병합 복잡성 감소 • Git-Flow 대비 관리 오버헤드 감소	• 까다로운 선제조건 • 큰 조직 규모에서는 페어 프로그래밍, 코드 리뷰만으로 관리 제한 • 개발 기능 볼륨이 크면 짧은 주기 병합 제한 • 바로 운영 환경에 배포될 때 잘못된 기능 배포가 이루어질 가능성 있음	선제 조건 충족이 가능한 경우