git 브랜치 전략과 git Flow

우리 회사에서도 당연히 git을 쓰고 있다. 그런데 각자 브랜치따는 방식이 다르고, 소스를 머지하면 일부 소스가 삭제되거나, 소스가 충돌되게 병합이 되는 현상들이 간혹 발생하는데, 왜그럴까? 생각해봤다. 

 

우선은 이전에 사용한 적 없는 브랜치 전략이기도 했고, 다소 낯설단 생각이 들었다. 하지만 이유가 있겠지 싶어서 그냥 따라보기로 했다. 

그런데 간혹, 간헐적으로 이런 현상이 발생하니 어떤 부분이 원래는 어떻게 돌아가는지 인지해야할 필요성을 느꼈다. 

 

브랜치 전략 

1. Git Flow

• 주로 사용하는 곳: 엔터프라이즈 환경, 장기적인 프로젝트
• 특징: 명확한 역할을 가진 브랜치를 사용하여 관리
• 브랜치 종류:
  • main (or master): 안정적인 배포 버전이 저장되는 브랜치
  • develop: 개발자들이 기능을 병합하는 브랜치
  • feature/: 개별 기능 개발을 위한 브랜치 (ex: feature/login)
  • release/: 배포를 준비하는 브랜치 (ex: release/1.2.0)
  • hotfix/: 긴급 수정 브랜치 (ex: hotfix/fix-bug-123)
• 장점: 안정적이고 체계적인 관리 가능
• 단점: 브랜치가 많아 관리가 복잡함

2. GitHub Flow

• 주로 사용하는 곳: 스타트업, 빠른 배포가 필요한 프로젝트
• 특징: main 브랜치와 기능 브랜치(feature)만 활용하는 단순한 전략
• 브랜치 종류:
  • main: 항상 배포 가능한 상태 유지
  • feature/: 기능을 추가할 때마다 새로운 브랜치 생성 후 PR (Pull Request)로 main에 병합
• 장점: 단순하고 빠른 배포 가능
• 단점: 배포 안정성이 낮을 수 있음

3. GitLab Flow

• 주로 사용하는 곳: CI/CD를 적극적으로 활용하는 회사
• 특징: GitHub Flow와 Git Flow의 중간 형태로, 환경별 브랜치를 운영
• 브랜치 종류:
  • main: 운영 환경(Production) 코드
  • pre-production (or staging, qa): 운영 직전 테스트용 브랜치
  • feature/: 기능 개발용 브랜치
• 장점: 환경별 배포 관리가 가능
• 단점: 환경별 브랜치가 많아질 경우 관리 부담

 

4. Trunk-Based Development

• 주로 사용하는 곳: 대규모 서비스 운영 (Google, Facebook 등)
• 특징: main 브랜치에서 직접 개발하고, 기능 브랜치는 짧게 유지
• 브랜치 종류:
  • main (or trunk): 모든 코드가 직접 커밋되는 브랜치
  • short-lived branches: 기능 개발 시 짧게 생성 후 바로 병합
• 장점: 빠른 배포, 단순한 브랜치 구조
• 단점: 여러 명이 동시에 작업하면 충돌이 자주 발생할 수 있음

 

어떤 전략을 선택해야 할까?

• 엔터프라이즈 환경: 안정성이 중요 → Git Flow
• 스타트업 & 빠른 배포: 신속한 개발 → GitHub Flow or Trunk-Based Development
• CI/CD 기반 개발: 환경별 관리 → GitLab Flow

지금 진행하는 Next.js + TypeScript 프로젝트에서는 배포가 빠르고 단순한 구조가 중요하므로 GitHub Flow 또는 Trunk-Based Development가 적합할 가능성이 높습니다. Vercel과 CI/CD 연계를 고려하면 GitHub Flow를 기반으로 운영하면서, 자동 배포를 활용하는 것도 좋은 선택이 될 수 있습니다.

 

 

브랜치 전략 : 

소프트웨어 개발에서 브랜치를 어떻게 생성하고 관리할 것인지에 대한 규칙과 프로세스를 의미하낟. 

하지만, 단순히 브랜치 구조만 나열하는 것이 아니라, 브랜치를 어떻게 운영할 것인지까지 포함해야 한다. 

 

예를 들면, 

1. 브랜치 생성 기준 

- 기능 개발을 위한 브랜치는 언제, 어떻게 생성하는가?

- 핫픽스는 어떤 방식으로 처리하는가?

 

2. 브랜치 머지(병합) 규칙

- main 브랜치에 직접 머지하는가, 아니면 중간 브랜치를 거치는가?

- PR 리뷰 프로세스는 어떻게 진행하는가? 

 

3. 배포 전략과 연계 

- 특정 브랜치가 특정환경과 어떻게 연동되는가?

- CI/CD와 어떻게 통합될 것인가? 

 

예를 들어, Git Flow 전략을 사용한다면 단순히 feature/, develop, main 브랜치가 있다는 설명만으로 끝나는 것이 아니라,

• feature 브랜치는 develop에서 분기하고, 개발이 끝나면 PR을 통해 develop에 병합한다.
• release 브랜치는 배포 전 단계에서만 사용하며, 버그 수정만 허용된다.
• hotfix 브랜치는 main에서 직접 분기하고, 수정 후 바로 main과 develop에 병합한다.

이런 세부적인 운영 방식까지 포함하는 것이 진짜 브랜치 전략이라고 할 수 있습니다.

 

 

그럼 그중에도 제일 많이 사용하는 Git Flow 전략을 살펴보자.

 

1. Git Flow 브랜치 구조

Git Flow에서는 5가지 주요 브랜치를 사용합니다.

① main 브랜치

• 배포된(production) 코드만 존재하는 브랜치
• 직접 커밋하지 않으며, release 또는 hotfix 브랜치에서만 병합 가능

② develop 브랜치

• 개발자들이 협업하는 기본 개발 브랜치
• 기능 개발이 끝난 feature 브랜치는 여기에 병합됨
• release 브랜치가 여기서 분기됨

③ feature 브랜치

• 새로운 기능을 개발할 때 생성하는 브랜치
• develop에서 분기하고, 개발이 완료되면 develop으로 병합
• 브랜치 이름 예시:
  bash

  복사편집

  git checkout -b feature/login

④ release 브랜치

• 배포를 준비하는 브랜치 (develop에서 분기)
• 여기서 버그 수정, QA 테스트 진행
• 완료되면 main에 병합하고, 태그(tag) 생성
• develop에도 다시 병합하여 동기화
• 브랜치 이름 예시:
  bash

  복사편집

  git checkout -b release/1.2.0 develop

⑤ hotfix 브랜치

• 프로덕션에서 긴급 버그가 발생했을 때 생성
• main에서 분기 후, 수정이 끝나면 main과 develop에 병합
• release를 거치지 않고 바로 배포 가능
• 브랜치 이름 예시:
  bash

  복사편집

  git checkout -b hotfix/fix-login-bug main

   

   

   

   

4. Git Flow의 장단점

✅ 장점

• 브랜치 역할이 명확하여 협업이 쉬움
• 프로덕션(main) 브랜치를 보호할 수 있음
• 안정적인 배포 및 버전 관리 가능

❌ 단점

• 브랜치가 많아 관리가 복잡해질 수 있음
• 빠른 배포(CI/CD)에 적합하지 않음 (ex: 빠르게 배포하는 SaaS 서비스)
• 작은 프로젝트에서는 불필요하게 무거울 수 있음

 

5. Git Flow를 사용할까?

• 기업용 프로젝트, 장기적인 서비스 개발에서는 안정성이 중요하므로 Git Flow가 적합
• 스타트업, 빠른 배포 환경에서는 GitHub Flow 또는 Trunk-Based Development가 더 나을 수 있음

---

 

우리의 브랜치 전략이 문제가 되는 이유 

왜 문제가 될까?

1. master에서 직접 feature 브랜치를 만드는 건 위험
   • 보통 develop에서 feature를 만들고 개발하는데, master에서 바로 feature를 따면 배포 코드와 개발 코드가 섞일 가능성이 있음.
   • master는 안정적인 배포 상태를 유지해야 하는데, feature가 여기서 분기되면 개발 중인 코드가 예기치 않게 반영될 위험이 있음.
2. feature → develop → feature → master로 병합하는 과정이 이상함
   • 보통 Git Flow에서는 feature → develop → release → master 순으로 가야 함.
   • 그런데 feature를 develop에 병합한 후 다시 feature를 master에 병합하면,
     개발 브랜치(unstable)에서 테스트한 코드가 다시 변경될 가능성이 생김.
   • 즉, develop에서 검증한 코드와 최종 배포된 코드가 다를 수도 있음.
3. 배포 및 코드 검증이 비효율적
   • 일반적인 배포 흐름에서는 develop에서 충분히 테스트한 후, release를 통해 안정성을 확인하고 master에 반영해야 함.
   • 그런데 feature를 develop에 넣었다가 다시 feature에서 master로 병합하면,
     배포 시점마다 코드가 달라질 위험이 커짐.

 

올바른 브랜치 전략 제안

1. Git Flow처럼 정리하는 방법

• develop에서 feature/* 브랜치 생성
• feature/*에서 개발 후 develop에 병합
• 테스트 후 release/* 브랜치 생성 (QA 진행)
• release/*에서 최종 검증 후 master에 병합하여 배포

plaintext

복사편집

master ----o---------o (배포)

\ / release o-------o (QA, 안정화)

\ / develop ----o---o-o---- (개발 코드)

\ / feature ---o-o------- (기능 개발)

 

결론: 현재의 브랜치 전략은 비효율적이고 리스크가 큼

• feature 브랜치를 master에서 생성하는 것은 위험함.
• feature가 develop을 거친 후 다시 master로 병합되는 구조도 비효율적임.
• 차라리 Git Flow나 GitHub Flow 같은 표준적인 전략을 도입하는 것이 훨씬 안정적이고 효율적임.

 

---

또 다른 팀에서 사용했던 브랜치 전략

✅ 이 전략의 흐름

1. develop에서 feature/* 브랜치 생성 (개발 시작)
2. feature/* 개발 완료 후 develop에 머지
3. develop에서 모든 기능이 완료되면 stage 브랜치로 머지
4. stage 환경에서 실제 라이브 DB를 사용하여 테스트
5. stage에서 문제가 없으면 master 브랜치에 머지하여 배포

🎯 이 전략의 장점

✅ 안정적인 배포 프로세스

• stage 환경에서 실제 DB와 같은 환경에서 사전 테스트가 가능해 배포 전 문제를 사전에 발견 가능
• develop은 자유롭게 개발할 수 있고, stage에서 최종 검증 후 배포하므로 신뢰성이 높음

✅ 협업이 효율적

• develop에서 여러 개발자들이 협업하고,
• stage에서 QA 및 운영팀이 최종 검증을 진행할 수 있어 역할 분리와 협업이 효과적

✅ 버그 최소화

• develop → stage → master의 흐름을 거치면서 검증 단계를 거치므로
• 직접 develop에서 master로 가는 것보다 버그가 줄어듦

 

⚠️ 고려해야 할 점

❌ 배포 속도가 느릴 수 있음

• stage 단계를 거쳐야 하므로, 긴급 배포(Hotfix)가 필요할 때 stage에서 지연될 가능성이 있음
• 하지만 hotfix/* 브랜치를 운영하여 master로 직접 머지하는 방식을 추가하면 해결 가능

❌ 테스트 환경 운영 비용

• stage 환경에서 라이브 DB를 복사해서 테스트하는 방식이라면,
  데이터 볼륨이 크거나 트래픽이 많을 경우 비용과 관리 부담이 생길 수 있음
• 이를 해결하려면 stage DB를 프로덕션과 유사하지만 트래픽이 적게 설정하는 방식이 필요

🔥 결론: 매우 좋은 전략!

예전에 사용했던 전략(develop → stage → master)은 안정성과 협업 측면에서 매우 좋은 브랜치 전략입니다.
특히, 운영 환경(프로덕션)에서 발생할 수 있는 문제를 미리 감지하는 데 효과적이므로
대규모 서비스, 금융권, 엔터프라이즈 환경에서 자주 사용됩니다.

🚀 적용하면 좋은 경우:

• 운영 환경의 안정성이 중요한 프로젝트
• QA 및 운영팀이 별도로 존재하는 경우
• 실무에서 실제 DB로 미리 테스트해야 하는 경우

⚡ 적용이 어려운 경우:

• 빠른 배포가 중요한 스타트업 환경
• 팀 규모가 작아서 QA 단계를 생략하는 경우