GitHub 프로젝트에서 브랜치의 생명주기

GitHub 프로젝트를 하다 보면 브랜치는 단순히 코드를 나누는 도구가 아니라, 작업의 상태를 표현하는 단위가 된다.

혼자 작업할 때는 브랜치가 임시 메모장처럼 느껴질 때도 있고, 팀 프로젝트에서는 “아직 main에 들어가면 안 되는 작업”을 격리하는 공간이 된다.

이번 글은 내가 직접 겪어본 개인 프로젝트와 팀 프로젝트의 브랜치 흐름을 중심으로 정리하고, 아직 직접 경험해보지 못한 회사 단위 프로젝트는 GitHub Flow, Gitflow, trunk-based development 자료를 찾아본 내용을 바탕으로 정리했다.

1. 브랜치의 생명주기란?

브랜치의 생명주기는 한 브랜치가 만들어지고, 사용되고, 리뷰되거나 병합되고, 마지막에 삭제되는 전체 흐름을 말한다.

보통 흐름은 다음과 같다.

  1. 작업 목적이 생긴다.
  2. 브랜치를 만든다.
  3. 브랜치에서 코드를 수정한다.
  4. 커밋하고 원격 저장소에 push한다.
  5. 필요하면 Pull Request를 만든다.
  6. 리뷰나 테스트를 거친다.
  7. main 또는 develop 같은 기준 브랜치에 merge한다.
  8. 역할이 끝난 브랜치를 삭제한다.

브랜치는 오래 살아있을수록 main과 차이가 커진다. 그러면 충돌이 늘어나고, 내가 만든 코드가 현재 프로젝트 상태와 맞지 않을 가능성도 커진다.

그래서 브랜치는 “필요할 때 만들고, 역할이 끝나면 정리하는 것”이 가장 기본적인 원칙이라고 느꼈다.

2. 개인 프로젝트에서의 브랜치 생명주기

개인 프로젝트에서는 브랜치 전략이 엄격할 필요는 없었다.

혼자 작업하기 때문에 누군가의 작업을 망가뜨릴 위험이 작고, 리뷰 승인이나 배포 일정도 대부분 내가 결정한다.

내가 개인 프로젝트에서 겪은 흐름은 대체로 이랬다.

main
  └─ feature/작업이름
        └─ 수정
        └─ 커밋
        └─ main에 병합
        └─ 브랜치 삭제

예를 들어 블로그 기능을 수정할 때는 main에서 바로 고칠 때도 있었고, 조금 길어질 것 같으면 feature/og-thumbnail 같은 브랜치를 만들어 작업했다.

개인 프로젝트에서 브랜치를 만드는 기준은 “이 작업이 바로 끝날까?”였다.

  • 오타 수정, 작은 문구 변경: main에서 바로 작업
  • 이미지, 레이아웃, 배포 설정처럼 실수하면 귀찮은 작업: 별도 브랜치
  • 여러 파일을 건드리는 작업: 별도 브랜치
  • 실험적인 기능: 별도 브랜치

개인 프로젝트에서 브랜치의 수명은 짧을수록 편했다. 하루 안에 끝나는 브랜치가 가장 부담이 없었다.

오래 남은 브랜치는 나중에 다시 볼 때 “이거 왜 만들었지?”가 되기 쉬웠다. 그래서 병합한 브랜치는 삭제하는 습관이 필요했다.

3. 팀 프로젝트에서의 브랜치 생명주기

팀 프로젝트에서는 브랜치가 단순한 작업 공간이 아니라 협업 약속이 된다.

내가 겪은 팀 프로젝트에서는 main 브랜치를 바로 건드리지 않고, 기능별로 브랜치를 만들어 작업한 뒤 Pull Request로 합치는 방식이 더 안정적이었다.

대략적인 흐름은 다음과 같았다.

main
  └─ feature/login-ui
  └─ feature/api-connect
  └─ fix/header-layout

각자 맡은 기능을 브랜치로 분리하면 동시에 작업하기가 쉬워진다. 한 사람이 로그인 UI를 만들고, 다른 사람이 API 연결을 하고, 또 다른 사람이 레이아웃 버그를 고쳐도 main은 비교적 안정적으로 유지된다.

팀 프로젝트에서 브랜치의 생명주기는 보통 이렇게 흘렀다.

  1. 이슈나 작업 단위가 정해진다.
  2. 작업 이름에 맞는 브랜치를 만든다.
  3. 자기 브랜치에서 기능을 구현한다.
  4. 중간중간 main의 최신 변경사항을 가져온다.
  5. 작업이 끝나면 Pull Request를 만든다.
  6. 팀원이 코드를 확인한다.
  7. 충돌이나 리뷰 내용을 반영한다.
  8. main에 merge한다.
  9. 브랜치를 삭제한다.

팀 프로젝트에서는 브랜치 이름도 꽤 중요했다.

test, final, real-final 같은 이름은 나중에 봤을 때 의미를 알기 어렵다.

반대로 feature/login-page, fix/nav-overlap, docs/readme-update처럼 목적이 보이는 이름은 훨씬 관리하기 쉬웠다.

내가 느낀 팀 프로젝트 브랜치의 핵심은 “내 작업을 남에게 설명할 수 있는 상태로 유지하는 것”이었다.

혼자라면 커밋 메시지가 조금 대충이어도 기억으로 버틸 수 있지만, 팀에서는 기억이 아니라 기록으로 협업해야 했다.

4. 개인 프로젝트와 팀 프로젝트의 차이

개인 프로젝트와 팀 프로젝트는 브랜치를 쓰는 이유가 조금 다르다.

구분 개인 프로젝트 팀 프로젝트
목적 내 작업 정리, 실험 분리 여러 사람의 작업 충돌 방지
main 보호 느슨해도 됨 강하게 보호하는 편이 좋음
Pull Request 선택 사항 거의 필수에 가까움
리뷰 스스로 확인 팀원 확인 필요
브랜치 수명 짧게 유지 짧게 유지하되 리뷰 시간 포함
삭제 기준 병합 후 삭제 PR merge 후 삭제

개인 프로젝트에서는 속도가 중요했다.

팀 프로젝트에서는 속도보다 “main이 망가지지 않는 것”이 더 중요했다.

5. 회사 단위 프로젝트는 어떻게 다를까?

회사 단위 프로젝트는 내가 아직 직접 겪어보지 못했다.

그래서 이 부분은 GitHub 공식 문서, Atlassian의 Gitflow 설명, trunk-based development 자료를 찾아보고 정리했다.

회사에서는 단순히 코드가 돌아가는지만 보는 것이 아니라 배포, QA, 승인, 장애 대응, 버전 관리까지 함께 고려해야 한다.

그래서 브랜치의 생명주기도 개인/팀 프로젝트보다 더 명확한 규칙을 가진다.

6. 회사에서 많이 보이는 흐름 1: GitHub Flow

GitHub 공식 문서에서 설명하는 GitHub Flow는 비교적 단순한 브랜치 기반 흐름이다.

main
  └─ feature branch
        └─ commit
        └─ pull request
        └─ review
        └─ merge
        └─ delete branch

GitHub Flow의 핵심은 main을 기준으로 짧은 브랜치를 만들고, Pull Request로 리뷰한 뒤, merge 후 브랜치를 삭제하는 것이다.

개인 프로젝트나 작은 팀 프로젝트에서 내가 겪었던 방식과도 꽤 비슷했다.

다만 회사에서는 여기에 자동 테스트, 코드 리뷰 승인, 브랜치 보호 규칙, 배포 파이프라인이 붙을 가능성이 크다.

즉, 흐름은 단순하지만 검증 장치가 더 많아지는 구조다.

이 방식은 웹 서비스처럼 자주 배포하고, main을 항상 배포 가능한 상태로 유지하려는 프로젝트에 잘 맞는다고 이해했다.

7. 회사에서 많이 보이는 흐름 2: Gitflow

Atlassian 문서에서 설명하는 Gitflow는 GitHub Flow보다 브랜치 종류가 많다.

대표적으로 다음 브랜치들이 등장한다.

  • main: 실제 배포된 안정 버전
  • develop: 다음 배포를 준비하는 개발 통합 브랜치
  • feature/*: 기능 개발 브랜치
  • release/*: 배포 직전 안정화 브랜치
  • hotfix/*: 운영 중인 버그를 빠르게 고치는 브랜치

흐름을 단순화하면 다음과 같다.

main
  └─ develop
        └─ feature/*
        └─ release/*
main
  └─ hotfix/*

Gitflow에서 브랜치의 생명주기는 목적에 따라 다르다.

feature 브랜치는 기능 개발이 끝나면 develop에 병합된다.

release 브랜치는 배포 전 QA나 버그 수정 기간에 사용되고, 배포 준비가 끝나면 main과 develop에 다시 병합된다.

hotfix 브랜치는 운영 중인 문제를 빠르게 고치기 위해 main에서 직접 갈라져 나오고, 수정 후 main과 develop에 반영된다.

이 방식은 배포 주기가 정해져 있거나, 운영 버전과 개발 버전을 분리해야 하는 회사 프로젝트에 적합해 보였다.

대신 브랜치가 많아서 관리 비용도 커진다. 작은 개인 프로젝트에 그대로 적용하면 오히려 부담이 될 수 있다.

8. 회사에서 많이 보이는 흐름 3: Trunk-Based Development

trunk-based development는 긴 수명의 개발 브랜치를 피하고, main 또는 trunk에 자주 통합하는 방식이다.

자료에서는 개발자들이 하나의 trunk를 중심으로 협업하고, 긴 브랜치를 만들지 않는 방향을 강조한다.

main 또는 trunk
  └─ short-lived branch
        └─ small commit
        └─ review/check
        └─ merge quickly

이 방식에서는 브랜치가 오래 살아있으면 안 된다.

작은 단위로 자주 합치고, 아직 사용자에게 보여주면 안 되는 기능은 feature flag 같은 방법으로 숨긴다.

회사 단위에서는 CI/CD가 잘 갖춰져 있고 테스트 자동화가 탄탄할수록 이런 방식이 가능해 보였다.

반대로 테스트가 부족하거나 리뷰 문화가 약한 상태에서 무작정 main에 자주 합치면 위험할 수도 있겠다고 느꼈다.

9. 프로젝트 성격별 브랜치 생명주기 정리

프로젝트 성격 추천 흐름 브랜치 수명 특징
개인 토이 프로젝트 main 직접 작업 또는 짧은 feature 브랜치 매우 짧게 속도와 실험이 중요
개인 포트폴리오/블로그 feature 브랜치 후 main 병합 짧게 배포 실수를 줄이는 것이 중요
학교/팀 프로젝트 feature 브랜치 + PR 짧게, 리뷰 후 삭제 역할 분담과 충돌 방지가 중요
작은 서비스 팀 GitHub Flow 짧게 PR, 테스트, main 보호가 중요
배포 주기가 있는 회사 프로젝트 Gitflow feature는 짧게, release는 배포 기간 동안 QA, 릴리즈, hotfix 관리가 중요
CI/CD가 강한 회사 프로젝트 Trunk-Based Development 아주 짧게 자동 테스트와 빠른 통합이 중요

결국 브랜치 전략은 멋있는 이름을 따르는 것이 아니라 프로젝트의 위험도와 협업 방식에 맞춰 선택해야 한다.

10. 내가 지금 가져갈 기준

내가 개인 프로젝트와 팀 프로젝트를 해보며 느낀 기준은 다음과 같다.

  • 혼자 작업해도 큰 변경은 브랜치를 만든다.
  • 팀에서는 main에 직접 push하지 않는다.
  • 브랜치 이름은 작업 목적이 보이게 짓는다.
  • 브랜치는 오래 살려두지 않는다.
  • 병합이 끝난 브랜치는 삭제한다.
  • Pull Request는 단순한 절차가 아니라 작업을 설명하는 기록이다.

회사 단위 프로젝트는 아직 경험해보지 않았지만, 자료를 찾아보며 느낀 점은 하나였다.

규모가 커질수록 브랜치는 “개발 편의”보다 “위험 관리”에 가까워진다.

개인 프로젝트에서는 브랜치가 내 실험 공간이고, 팀 프로젝트에서는 협업 단위이며, 회사 프로젝트에서는 배포와 품질을 지키는 통제 지점이 된다.

참고 자료