Crontab 파이썬 스크립트 실행 안될 때 환경변수 PATH 문제 해결 완벽 정리

날짜:
0

Git Flow vs GitHub Flow 우리 팀에 맞는 브랜치 전략은

날짜:
브랜치 전략 없이 개발하다가 배포 직전 충돌 지옥에 빠지거나, 핫픽스 하나 배포하는데 develop 브랜치까지 꼬여본 경험이 있다면 이 글이 필요합니다. Git Flow와 GitHub Flow는 각각 명확한 적용 시나리오가 있으며, 팀 규모와 배포 주기에 따라 선택 기준이 달라집니다. 이 글에서는 두 전략의 핵심 차이점과 실무 적용 커맨드, 그리고 실제 운영 중 마주한 트러블슈팅 경험을 코드 중심으로 정리합니다.


배포 주기로 결정하는 브랜치 전략 Git Flow vs GitHub Flow




1. 브랜치 전략이 필요한 이유

브랜치 전략은 여러 개발자가 하나의 저장소에서 작업할 때 발생하는 충돌과 릴리즈 혼란을 방지하기 위한 브랜치 생성·병합·삭제 규칙입니다. 전략 없이 main 브랜치에 직접 커밋하면 다음 문제가 발생합니다.

  • 롤백 불가: 특정 기능만 제거하려 해도 커밋 히스토리가 뒤섞여 있어 revert가 복잡해집니다.
  • QA 불가: 개발 중인 기능과 배포 예정 기능이 섞여 있어 릴리즈 범위를 특정할 수 없습니다.
  • 핫픽스 지연: 긴급 버그를 수정해도 미완성 기능이 함께 배포될 위험이 있습니다.

결국 브랜치 전략은 릴리즈 단위를 명확히 하고, 히스토리를 추적 가능하게 만드는 것이 목적입니다. 팀 규모가 2명이든 20명이든, 배포 주기가 1일이든 1개월이든 전략은 필요합니다.

2. Git Flow: 복잡한 릴리즈 프로세스를 위한 5-브랜치 모델

Git Flow는 main(master), develop, feature, release, hotfix 5가지 브랜치 타입으로 구성되며, 정기 배포 주기를 가진 프로젝트(모바일 앱, 패키지 소프트웨어 등)에 적합합니다.

브랜치 역할 및 생명주기

  • main: 프로덕션 배포 이력만 존재. 모든 커밋은 태그로 버전 관리.
  • develop: 다음 릴리즈를 위한 개발 통합 브랜치. feature들이 여기로 병합됩니다.
  • feature/*: 개별 기능 개발용. develop에서 분기하고 완료 후 다시 develop으로 병합.
  • release/*: QA 및 배포 준비용. develop에서 분기하여 버그 수정 후 main과 develop에 병합.
  • hotfix/*: 프로덕션 긴급 수정용. main에서 분기하여 수정 후 main과 develop에 병합.

핵심 커맨드 시퀀스

Feature 브랜치 워크플로우:

# 1. develop 최신화
git checkout develop
git pull origin develop

# 2. feature 브랜치 생성 (develop 기준)
git checkout -b feature/login develop

# 3. 작업 후 커밋
git add .
git commit -m "feat: OAuth2 로그인 구현"

# 4. develop에 병합 (--no-ff로 merge commit 유지)
git checkout develop
git merge --no-ff feature/login

# 5. 브랜치 삭제
git branch -d feature/login
git push origin --delete feature/login

Hotfix 브랜치 워크플로우:

# 1. main에서 hotfix 브랜치 생성
git checkout -b hotfix-1.2.1 main

# 2. 버그 수정 및 버전 업데이트 (package.json, pom.xml 등)
git commit -m "fix: 결제 모듈 null pointer 수정"

# 3. main에 병합 및 태깅
git checkout main
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1 -m "Release 1.2.1"

# 4. develop에도 동일 수정 반영
git checkout develop
git merge --no-ff hotfix-1.2.1

# 5. hotfix 브랜치 삭제
git branch -d hotfix-1.2.1

실무 적용 시 주의사항

  • --no-ff 옵션 필수: Fast-Forward 병합을 방지하고 Merge Commit을 남겨야 기능 단위 히스토리가 명확해집니다. Git 설정에서 git config --global merge.ff false로 기본값 변경을 권장합니다.
  • feature 브랜치는 원칙적으로 로컬 전용이나, 협업 시 원격 push + PR 권장: 코드리뷰 없이 develop에 직접 병합하면 품질 관리가 불가능합니다.
  • release 브랜치에서 새 기능 추가 금지: 버그 수정과 버전 번호 업데이트만 허용. 새 기능은 다음 릴리즈로 미룹니다.

3. GitHub Flow: 지속적 배포를 위한 단순 모델

GitHub Flow는 main 브랜치 + 토픽 브랜치 2가지만 사용하며, CI/CD 파이프라인이 구축된 웹 서비스에 적합합니다. 배포 주기가 하루에도 수십 번인 환경에서 Git Flow의 복잡한 절차는 오버헤드입니다.

워크플로우 5단계

  1. main에서 토픽 브랜치 생성: git checkout -b feature/user-profile main
  2. 작업 후 원격 push: git push origin feature/user-profile
  3. Pull Request 생성: GitHub/GitLab UI에서 PR 오픈. 초기 아이디어 공유를 위해 WIP(Work In Progress) PR도 활용 가능.
  4. 코드리뷰 및 CI 통과: 리뷰어 승인 + 자동화된 테스트 통과 확인.
  5. main 병합 및 자동 배포: PR 머지 시 CI/CD 파이프라인이 자동으로 프로덕션 배포.

Git Flow와의 핵심 차이점

항목 Git Flow GitHub Flow
브랜치 수 5개 (main, develop, feature, release, hotfix) 2개 (main, topic)
배포 주기 정기 배포 (주/월 단위) 지속적 배포 (커밋 단위)
핫픽스 처리 별도 hotfix 브랜치 → main & develop 병합 main에서 브랜치 → 수정 → PR → main 병합
적합 환경 모바일 앱, 패키지 SW SaaS, 웹 서비스

실무 팁

  • 토픽 브랜치는 자주 push: 로컬에만 두면 디스크 장애 시 작업 유실. 하루 1회 이상 원격 push를 권장합니다.
  • PR은 빨리, 작게: 500줄 이상 코드 변경은 리뷰어가 포기합니다. 기능을 작은 단위로 쪼개고 PR을 여러 개 나눕니다.
  • main 브랜치 보호 규칙 설정: GitHub Settings에서 "Require pull request reviews before merging" + "Require status checks to pass" 활성화 필수.

4. 우리 팀에 맞는 전략 선택 기준

브랜치 전략은 팀 규모나 기술 스택이 아니라 배포 주기와 롤백 정책으로 결정됩니다.

Git Flow를 선택해야 하는 경우

  • 앱스토어 심사 등으로 배포 주기가 주 단위 이상인 경우
  • 여러 버전을 동시에 지원해야 하는 경우 (예: v1.x, v2.x 병렬 유지보수)
  • QA 팀이 별도로 존재하고 릴리즈 전 테스트 기간이 필요한 경우

GitHub Flow를 선택해야 하는 경우

  • 배포 주기가 일 단위 이하이고 롤백이 자유로운 경우
  • CI/CD 파이프라인이 구축되어 있고 자동화된 테스트 커버리지가 70% 이상인 경우
  • 팀 규모가 5명 이하이거나 스타트업 초기 단계인 경우

실전 적용 경험

초기 프로젝트에서 Git Flow를 적용했으나 develop 브랜치가 병목이 되어 feature 병합이 지연되는 문제가 발생했습니다. 배포 주기를 주 1회에서 일 2회로 변경하면서 GitHub Flow로 전환했고, PR 기반 코드리뷰와 자동화된 E2E 테스트로 품질을 보완했습니다. 단, 긴급 버그는 main에서 hotfix 브랜치를 생성하고 수정 후 태그를 달아 릴리즈 버전을 명확히 관리했습니다. 태깅 없이 배포하면 특정 시점의 소스코드를 찾을 수 없어 롤백이 불가능합니다.

브랜치 네이밍 컨벤션

전략과 무관하게 다음 규칙을 권장합니다.

  • feature/기능명: feature/oauth-login (kebab-case 사용)
  • bugfix/이슈번호: bugfix/JIRA-1234
  • hotfix-버전: hotfix-1.2.1 (하이픈으로 구분)
  • 금지 패턴: main, master, develop, release- 등 전략 키워드와 중복 금지

정리 및 Action Item

Git Flow는 릴리즈 프로세스가 복잡하고 QA 기간이 필요한 프로젝트에, GitHub Flow는 지속적 배포 환경에 적합합니다. 중요한 것은 전략 자체가 아니라 팀 전체가 동일한 규칙을 따르고, --no-ff 병합과 태깅으로 히스토리를 명확히 관리하는 것입니다. 협업 환경에서는 feature 브랜치를 원격에 push하고 PR 기반 코드리뷰를 필수화하며, 긴급 수정은 반드시 main과 develop 양쪽에 병합하여 동기화를 유지해야 합니다.

Action Item: 현재 프로젝트의 배포 주기를 확인하고, 일 단위 이하라면 GitHub Flow로, 주 단위 이상이라면 Git Flow로 브랜치 전략을 정의하십시오. 그리고 git config --global merge.ff false 명령으로 --no-ff를 기본값으로 설정하여 Merge Commit이 자동으로 생성되도록 환경을 구성하십시오.


#함께 읽으면 좋은 글

Redis란 무엇인가 인메모리 캐싱으로 웹 성능 10배 높이는 법 : 바로보기

댓글

댓글 쓰기