본문 바로가기
카테고리 없음

Git 워킹 브랜치 전략: Long Running Strategy

by logsome 2025. 3. 8.

Git Working Branch Strategy

1. 워킹 브랜치 전략이란?

Git에서 워킹 브랜치(Working Branch) 전략은 특정 작업을 분리하여 장기간 유지하면서 개발하는 브랜치 전략을 의미합니다. 이는 특히 다음과 같은 상황에서 유용합니다:

  • 업무가 여러 개일 때: 배포 일정이 확정되지 않았거나 프로토타입을 진행해야 할 경우, 실서비스 코드에서 격리하여 안정적으로 개발할 수 있습니다.
  • 업무가 클 때: 대규모 기능을 개발할 때 작업 단위를 나누어 코드 리뷰와 협업을 용이하게 할 수 있습니다.

이 전략을 활용하면 장기간 유지해야 하는 개발 작업을 효과적으로 관리하고, 배포 시의 리스크를 줄이는 데 도움이 됩니다.


2. 기존 브랜치 전략과 문제점

일반적으로 Git 브랜치는 정적 구조로 운영됩니다. 간단한 예시로 다음과 같은 브랜치 전략을 생각해볼 수 있습니다:

  • main: 운영(default) 브랜치, 가장 최신의 배포 코드가 포함된 브랜치
  • dev: 개발 서버에 배포되는 브랜치
  • feature/MYPROJECT-1: 기능 개발을 위한 작업 브랜치, main 브랜치에서 생성하여 진행

하지만 이러한 전략을 사용할 때 다음과 같은 문제점이 발생할 수 있습니다.

1) 코드 리뷰의 어려움

작업이 작을 것으로 예상했지만 요구사항이 추가되어 file changed가 100개 이상이 되는 경우 코드 리뷰가 어렵습니다. 코드 변경량이 많아질수록 리뷰 시간이 길어지고, 오류가 발생할 가능성도 커집니다.

2) 특정 작업만 되돌리기 어려움

배포일이 같아 feature/MYPROJECT-1 브랜치에서 A, B, C 작업을 모두 포함했는데, B 작업만 제거해야 하는 상황이 발생할 수 있습니다. B를 되돌리려면 B에 관련된 작업  커밋들을 하나하나 추적해야하며 A와 C도 B 작업과 함께 코드 변경이 포함되어 있다면, 모든 작업을 다시 테스트해야 할 수도 있습니다.


3. 워킹 브랜치 전략 적용 방법

이러한 문제를 해결하기 위해 워킹 브랜치 전략을 도입할 수 있습니다.

1) 워킹 브랜치 생성

  • main 브랜치에서 워킹 브랜치를 생성합니다.
    • 예시: working/MYPROJECT-1
  • 추가적인 구분을 위해 postfix를 붙일 수도 있습니다.
    • 예시: working/MYPROJECT-1_refactor, working/MYPROJECT-1_250308

2) 작업 브랜치 생성 및 관리

  • 작업 브랜치는 워킹 브랜치에서 생성합니다.
  • 작업이 끝나면 워킹 브랜치로 feature 브랜치를 머지합니다.
  • main 브랜치에서 변경 사항이 생기면 main -> working -> feature 순서로 머지하여 동기화합니다.

3) 코드 리뷰 개선

  • 워킹 브랜치에서 feature 브랜치들을 분리하여 작업하다보면 공통 모듈 처럼 여러 기능에서 사용해야 하는 경우, 여러 feature 브랜치에서 공통 모듈 feature 브랜치에 의존적이게 됩니다. 이를 분리하지 않고 하나의 feature 에서 공통 모듈과 다른 기능까지 개발한다면 코드 리뷰 단위가 커져 코드 리뷰가 어려워 지는 등 워킹 브랜치의 장점을 . 예를들어 A작업에 B 작업이 의존적인 경우
    • feature/B → feature/A → 워킹 브랜치 순으로 머지
    • 또는 각각 feature/A, feature/B 를 워킹 브랜치에서 생성하고, feature/A 작업 후, feature/B 브랜치에 feature/A 를 머지합니다. 이후 워킹 브랜치에는 feature/A → 워킹 브랜치로 A 브랜치가 워킹 브랜치에 반영된 이후에 feature/B -> 워킹 브랜치 순으로 머지합니다.
  • 이를 통해 코드 변경 범위를 최소화하고, 코드 리뷰를 쉽게 진행할 수 있습니다.

4) 모든 작업 완료 이후 배포 준비

  • 모든 작업이 완료되면 워킹 브랜치를 dev, main 브랜치 등에 머지하여 배포합니다.
  • 전략에 따라 dev 브랜치에서 테스트한 후, 검증된 작업만 워킹 브랜치로 머지하는 방법도 있습니다.

4. 실무에서의 활용

실제 프로젝트에서는 prod, sandbox, cbt 등 여러 개발 환경이 존재하여 브랜치 전략이 더 복잡하고 예시로 든 정적 브랜치가 아니라 동적 브랜치를 사용하는 경우도 많습니다.

워킹 브랜치를 활용하면 대규모 작업을 효과적으로 분리하고, 코드 리뷰와 배포를 원활하게 할 수 있다는 점에서 유용하기 때문에

만약 현재 팀에서 브랜치 전략과 관련한 문제를 겪고 있다면, 워킹 브랜치 전략을 도입하여 관리 방식 개선을 고려해 볼 수 있습니다.