[GIT] 팀장의 사고를 배우는 깃 브랜치 전략

6 min readAug 29, 2023

혹시 깃 브랜치 전략을 당연하게도 Git-Flow전략을 채택하고 사용하고 있는가? 이 글은 그런 개발자들에게 “사고”를 불어넣어줄 글이다.

당장! 의미 없이 브랜치를 파는 것을 멈추고 왜 무수히 많은 Pull Request과 Merge를 날려야하는지 스스로 고민해보는 시간을 갖자.

당연한 이야기지만 수많은 브랜치 전략들 중 어느 것이 최고의 방식이라 딱 집어 이야기 할 수 없다. 다만, 우리는 “상황에 맞는 최적의 전략”을 찾는 것에 집중해야 한다.

각 프로젝트를 수행하는 팀원들의 성향과 프로젝트 규모, 투입 인원, 기간 등 수 많은 요소들을 고려해 각 팀과 프로젝트의 색깔에 맞추어 전략을 수정해야 한다. 이는 팀 리더의 중요한 역할 중 하나이며, 앞으로 무수히 겪어야 하는 “의사결정”의 과정이다.

자, 이제부터 우리는 총 4가지의 브랜치 전략을 배우고 언제 어느 상황에서 어떤 브랜치 전략을 사용해야 하는지 이해해 나갈 것이다.

깃 브랜치 전략 알아가기

우선 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 Work-Flow라는 것을 이해해야 한다.

그렇기에 브랜치 전략을 고려할 때 팀원들의 성향과 프로젝트 규모, 투입 인원, 기간 등 수 많은 요소들을 고려하는 것이다. 해당 요소들의 관점에서 다양한 브랜치 전략을 살펴보자. (간략하게 살펴볼 예정이다. 하나 하나 깊게 살펴보는 글을 추후 작성하도록 하겠다.)

Git-Flow 브랜치 전략

다음의 사진을 수도 없이 보았을 것이다. 해당 브랜치 전략은 Vincent Driessen이 제안한 브랜치 전략으로, 큰 규모의 프로젝트에 적합하고 명확한 구조를 제공한다.

개발 기간이 2주 이상으로 길거나, 협업하는 개발자가 많아지는 경우에 더욱 필요로 한다.

release 브랜치에서 서비스 버전 단위의 QA를 진행하고 Bug Fix를 진행하는 프로세스로 진행된다.

Github-Flow 브랜치 전략

GitHub Flow는 Git Flow보다 간소화된 프로세스로, 빠른 개발 사이클을 가진 프로젝트에 적합하다. Feature 브랜치의 이름은 자세하게 어떤 일을 하는지에 대해 작성하고 피드백이 충분히 거쳐진 상황에서 master(mainline)에 merge하여 즉시 배포가 되게 하는 방법이다.

GitLab-Flow 브랜치 전략

GitLab Flow는 Git Flow와 GitHub Flow의 장점을 결합한 유연한 브랜치 전략으로, 다양한 환경에서 코드를 배포하고 관리하는 데 사용된다.

이 전략은 명료하게 work flow를 표현할 수 있고 Git Flow보다 비교적 단순하다는 장점이 있다. GitHub Flow에 비해 보다 더 조직적이고 구조화된 구조로 안정성이 있으며 작은 수정 후에도 지속적인 버전 관리 및 배포가 용이하다는 특징도 있다.

Trunk-based Development

TBD의 특징은 모든 개발자가 트렁크(trunk or master)라는 단일 브랜치에서 직접 모든 작업을 하는 것이다. 이런 구조는 GitHub Flow와 똑같아 보일 수 있다. 하지만 아래와 같은 몇 가지 절대적이고 안전한 규칙들을 지켜야만 한다.

Pair Programming
Mob Programming
신뢰할 수 있는 빌드가 필요
‘Branch by Abstraction’ 또는 ‘Feature Flags’를 사용하여 작업이 완료되지 않는 부분 숨기기
소규모 배치로 개발
빠른 빌드

[참고] Trunk-based development(TBD)(참고: 블로그)

프로젝트에 깃 브랜치 전략 적용하기

필자는 기본적으로 Git-Flow 브랜치 전략을 사용해왔다. 외주 및 팀 프로젝트에서 3명 이상의 개발자와 일하는 과정을 겪어왔고 서비스를 버전 단위로 개발, 테스트, 배포를 진행해왔기 때문이다.

이번 소프트웨어 마에스트로 14기에 참여하여 진행하는 프로젝트 또한 당연히 그렇게 개발을 해야지 라는 생각으로 진행을 했다.

하지만, 여기서 큰 잘못이 있었다. “의심”을 전혀 하지 않았다는 것이다.

의문을 하기 시작하면서 필자는 다음과 같이 프로젝트의 상황을 점검하였다.

웹 서비스 개발을 하며, 기능 단위의 Release가 발생
빠른 테스트 및 배포 과정의 필요성
1인 FE 개발 체계
2주 단위 Sprint 기반의 Agile 방법론을 통한 기능 단위 배포
실사용자 피드백을 통해 기능 반복 개선

해당 상황에서 복잡한 브랜치 전략이 아닌 “빠른 테스트 및 배포”가 가능한 브랜치 전략이 필요했다. 번거로운 브랜치 병합 과정을 최소화하고 기능 단위 테스트를 하고 바로 배포할 수 있도록 지원해야 했다.

바로 복잡한 Git-Flow 브랜치 전략을 버리고 나머지 전략 중에 Github-Flow를 채택하게 되었다. 이를 채택하게된 계기는 딱 하나다.

“기능 단위의 빠른 테스트 및 배포의 지원을 통해 실사용자의 피드백 기반의 반복 개선이 가능함”

의사결정을 통한 브랜치 전략 변화는 다음과 같은 장점을 가져왔다.

01. 의미없는 Pull Request의 횟수 감소 (시간 비용 감소)
02. 브랜치 수 간소화
03. 서비스 버전 별 기능 테스트 및 배포가 아닌 기능별 테스트 및 배포
(더 작은 단위의 배포 가능)

맺음말

필자는 “당연하게 하고 있는 행위”에 대한 의구심을 품고 정확한 지식을 알고 의사결정을 하는 과정을 진행하였다. 당연한 것처럼 보이는 것들에 대해 한번 더 생각하게 되었고, 생각과 태도의 발전을 이룰 수 있었다.

어떤가? 이번 글을 통해 당연히 알고 있었던 개념들이지만 한 번 다시 생각해본 계기가 되지 않았는가?

필자는 해당 관점으로 당연한 것들 또는 새로운 것들에 대한 “WHY”를 생각해보는 사람으로 발전해나가려고 한다. 글이 마음에 든다면 필자와 함께 “WHY”를 질문하고 이에 대해 스스로의 답을 찾아가는 개발자로 성장해나가보자.