Git

[Git] 복잡한 프로젝트를 관리하는 Git Flow 브랜치 전략

MayQ 2025. 6. 3. 21:44

출처: https://brntn.me/blog/git-branching-strategy-diagrams/

프로젝트 관리 효율성을 높이는 Git Flow 전략

Git Flow는 Vincent Driessen이 제안한 Git 브랜칭 모델로, 개발팀이 여러 브랜치를 사용하여 기능 개발, 릴리스 준비, 핫픽스 적용을 효율적으로 관리할 수 있도록 도와줍니다. Git Flow는 주로 복잡한 프로젝트나 명확한 릴리스 주기가 있는 프로젝트에서 사용되며, 개발 과정에서 구조화된 작업 흐름을 제공합니다​.

주요 브랜치

  1. 메인(Main) 브랜치:
    • 이 브랜치는 현재 프로덕션 상태의 코드만 포함하며, 항상 안정적인 버전의 코드를 반영합니다. 새로운 기능이나 변경 사항은 이 브랜치로 직접 반영되지 않으며, 릴리스와 핫픽스 브랜치에서만 머지됩니다​.
  2. 개발(Develop) 브랜치:
    • 모든 기능 브랜치가 이 브랜치에 병합되며, 다음 릴리스를 준비하기 위한 통합 지점입니다. 개발 과정의 가장 최신 상태를 반영하며, 주기적으로 메인 브랜치로 머지되어 릴리스를 준비합니다.

서포팅 브랜치

  1. 기능(Feature) 브랜치:
    • 기능 개발을 위해 develop 브랜치에서 분기하며, 기능이 완성되면 다시 develop 브랜치로 머지됩니다. 이 브랜치의 목적은 각각의 기능 개발이 독립적으로 진행되어 개발 브랜치의 안정성을 유지하는 것입니다​.
  2. 릴리스(Release) 브랜치:
    • 다음 릴리스가 준비될 때 develop 브랜치에서 분기됩니다. 여기서 버그 수정, 버전 번호 업데이트 등 최종 작업을 진행하며, 모든 것이 준비되면 main 브랜치로 머지되어 프로덕션에 배포됩니다. 릴리스가 완료되면 다시 develop 브랜치로도 병합하여, 릴리스 과정에서의 변경 사항이 이후의 개발에도 반영되도록 합니다​.
  3. 핫픽스(Hotfix) 브랜치:
    • 프로덕션에서 발생한 긴급한 버그를 수정하기 위해 main 브랜치에서 바로 분기됩니다. 수정 사항은 프로덕션에 바로 반영되어야 하므로, 핫픽스가 완료되면 main과 develop 브랜치 모두에 병합됩니다​.

Git Flow 사용 방법

Git Flow를 사용하기 위해서는 우선

  1. 기본 브랜치를 설정해야 합니다.
  2. git init으로 저장소를 초기화한 후,
  3. develop 브랜치를 생성하여 개발의 기본 브랜치로 사용합니다.
  4. 각 기능은 develop에서 분기된 feature 브랜치에서 개발하고,
  5. 기능이 완료되면 다시 develop에 병합합니다.
  6. 릴리스 준비가 완료되면 develop에서 release 브랜치를 생성하여 마지막 수정을 진행하고,
  7. 그 후 main에 머지합니다.
  8. 긴급한 수정은 hotfix 브랜치를 통해 처리됩니다

Git Flow의 장단점

장점

  1. 분리된 작업 환경:
    • 기능, 릴리스, 핫픽스 작업을 별도의 브랜치에서 진행하므로 코드 안정성이 높고, 각 작업이 명확히 구분됩니다​.
  2. 안정된 프로덕션:
    • main 브랜치는 항상 안정적인 상태를 유지하고, 검증된 코드만 병합되기 때문에 프로덕션 환경에서의 문제 발생을 최소화할 수 있습니다​.
  3. 팀 협업 효율성:
    • 여러 명의 개발자가 각각의 feature 브랜치에서 작업할 수 있으므로, 충돌이 적고 병합 과정이 원활합니다. 또한 기능이 독립적으로 개발되기 때문에, 특정 기능의 개발 상태가 전체 개발 과정에 영향을 미치지 않습니다​.

단점

  1. 복잡한 브랜치 관리:
    • 많은 브랜치를 유지해야 하므로, 브랜치 관리가 복잡해질 수 있습니다. 특히 대규모 프로젝트에서는 브랜치 간의 충돌을 해결하는 데 시간이 걸릴 수 있습니다​.
  2. 지연된 병합:
    • feature 브랜치에서 오래 작업한 후 병합할 때 충돌이 발생할 가능성이 높으며, 이는 병합 과정에서 시간이 더 소요될 수 있습니다​.
  3. CI/CD 환경과의 부적합성:
    • Git Flow는 CI/CD(Continuous Integration/Continuous Delivery) 환경에서 사용하기에 적합하지 않은 경우가 많습니다. 긴 릴리스 주기가 있을 때는 잘 맞지만, 지속적인 배포를 요구하는 경우에는 브랜치가 많아 관리가 어려워질 수 있습니다​.

이미지를 통해 알아보는 Git Flow 전략 진행 예제

출처: https://brntn.me/blog/git-branching-strategy-diagrams/

1. Tag 0.1 - 첫 번째 릴리스

  • 초기 릴리스가 main 브랜치에서 이루어졌으며, Tag: 0.1으로 태그가 지정되었습니다.
  • 설명: Git Flow에서는 항상 안정된 코드만 main 브랜치에 병합되며, 이 태그는 첫 번째 배포된 버전을 나타냅니다.

2. 핫픽스 브랜치

  • 0.1 버전 릴리스 이후, 심각한 버그가 발견되어 main 브랜치에서 핫픽스 브랜치가 생성되었습니다.
    • Severe bug fix for 0.1 release: 버그를 수정한 후 main 브랜치에 다시 병합되었습니다.
    • Bugfix is merged to develop: 동시에 이 수정 사항이 develop 브랜치에도 반영되었습니다.

핫픽스 처리 절차

  • main에서 핫픽스 브랜치를 생성
git checkout -b hotfix/0.1.1 main
  • 수정한 후, main과 develop에 모두 병합
git checkout main
git merge --no-ff hotfix/0.1.1
git checkout develop
git merge --no-ff hotfix/0.1.1

3. Tag 0.2 - 두 번째 릴리스

  • 두 번째 릴리스가 main 브랜치에 Tag: 0.2로 릴리스되었습니다. 이 시점에서는 핫픽스가 적용된 버그 수정 사항이 포함된 안정된 버전입니다.
  • 설명: 핫픽스를 통해 수정된 사항을 반영한 후, 새로운 안정된 릴리스가 이루어졌습니다.

4. 기능 개발 및 통합

  • 주요 기능들이 develop 브랜치에서 독립적인 기능 브랜치로 개발되었습니다. 이 과정은 develop 브랜치에 기능을 통합하는 방식으로 진행됩니다.
    • Major feature for 1.0: 주요 기능은 develop 브랜치에서 기능별로 작업이 이루어지고, 각 기능이 완료되면 다시 develop에 병합됩니다.

기능 개발 절차

  • 기능 브랜치를 생성하여 작업
git checkout -b feature/awesome-feature develop
  • 작업 완료 후 develop에 병합
git checkout develop
git merge --no-ff feature/awesome-feature
git branch -d feature/awesome-feature

5. 릴리스 브랜치 생성

  • 기능들이 완성되고 통합되면, develop 브랜치에서 릴리스 브랜치를 생성합니다. 이 브랜치는 최종 릴리스를 준비하는 과정에서 버그 수정 및 최종 테스트를 진행합니다.
    • Release branch for 1.0: 이 브랜치에서 수정된 사항은 main 브랜치에 병합되기 전에 마지막으로 다듬어집니다.
    • Fixes on release branch merged back to develop: 릴리스 브랜치에서 수정된 사항은 다시 develop에도 병합됩니다.

릴리스 브랜치 생성 및 병합 절차

  • develop에서 릴리스 브랜치 생성bash코드 복사
git checkout -b release/1.0 develop
  • 수정 완료 후 main과 develop에 병합
git checkout main
git merge --no-ff release/1.0
git checkout develop
git merge --no-ff release/1.0
git branch -d release/1.0

6. Tag 1.0 - 최종 릴리스

  • 1.0 릴리스가 main 브랜치에 병합되어 배포되었습니다.
  • 설명: 최종 릴리스가 완료된 후 Tag: 1.0으로 지정되어 안정적인 버전이 배포되었습니다.

7. 다음 릴리스 준비

  • From this point on, "next release" is after 1.0: 1.0 릴리스 이후, develop 브랜치에서 다음 릴리스를 위한 기능들이 개발되고 있으며, 새로운 기능들은 feature 브랜치에서 작업된 후 다시 develop에 통합됩니다.
  • 이처럼 새로운 기능 개발은 develop 브랜치에서 계속해서 이루어지며, 이후 또다시 릴리스 브랜치가 생성되어 최종 릴리스가 이루어집니다.

이 이미지는 Git Flow 전략이 어떻게 기능 개발, 핫픽스 처리, 릴리스 준비, 그리고 최종 릴리스를 체계적으로 관리하는지를 잘 보여줍니다. 기능 개발은 독립적인 브랜치에서 이루어지고, 핫픽스는 즉각적으로 반영되며, 최종 릴리스는 릴리스 브랜치에서 이루어집니다.

다른 Git Flow 사용 예시 시나리오: 웹 애플리케이션 개발

다음은 웹 애플리케이션 개발에서 Git Flow 전략을 사용하는 예시 시나리오를 단계별로 설명하고, 각 단계에서 필요한 명령어를 코드 블록으로 정리한 것입니다.

1. Develop 브랜치 생성

모든 개발 작업은 develop 브랜치에서 이루어집니다. 이 브랜치는 현재 개발 중인 기능들을 통합하는 브랜치로, 최종적으로 릴리스할 준비가 되면 release 브랜치로 분기됩니다.

# develop 브랜치 생성
git checkout -b develop main

2. 기능 개발 (Feature 브랜치)

새로운 기능을 추가하기 위해 각 개발자는 develop 브랜치에서 새로운 feature 브랜치를 만듭니다. 예를 들어, 로그인 기능을 개발한다고 가정할 때, feature/login 브랜치를 생성하여 개발을 시작합니다.

# feature/login 브랜치 생성 및 이동
git checkout -b feature/login develop

# 코드 작성 및 커밋
git add .
git commit -m "Implement login feature"

3. 기능 병합

로그인 기능이 완성되면, feature/login 브랜치를 develop 브랜치로 병합합니다.

# develop 브랜치로 이동
git checkout develop

# feature/login 브랜치를 develop에 병합
git merge --no-ff feature/login

# 사용이 끝난 feature 브랜치 삭제
git branch -d feature/login

4. 릴리스 준비 (Release 브랜치)

여러 기능이 완료되면, develop 브랜치에서 릴리스 브랜치를 생성합니다. 이 릴리스 브랜치에서는 최종적인 버그 수정과 테스트를 진행합니다.

# 릴리스 브랜치 생성
git checkout -b release/1.0 develop

# 버그 수정 및 테스트 후 커밋
git add .
git commit -m "Final bug fixes and preparation for release"

5. 프로덕션 반영 (Release 브랜치 병합)

모든 테스트가 완료되면, release 브랜치를 main에 병합하여 프로덕션에 반영합니다. 이후 release 브랜치의 수정사항도 develop 브랜치에 반영합니다.

# release 브랜치를 main에 병합
git checkout main
git merge --no-ff release/1.0

# main 브랜치에 릴리스 버전 태그 추가
git tag -a 1.0 -m "Version 1.0 release"

# release 브랜치를 develop에 병합
git checkout develop
git merge --no-ff release/1.0

# 사용이 끝난 릴리스 브랜치 삭제
git branch -d release/1.0

6. 핫픽스 처리 (Hotfix 브랜치)

프로덕션에서 버그가 발생한 경우, main 브랜치에서 핫픽스 브랜치를 생성하여 긴급 수정합니다. 수정 후, main과 develop 브랜치에 모두 병합합니다.

# main에서 핫픽스 브랜치 생성
git checkout -b hotfix/1.0.1 main

# 버그 수정 및 커밋
git add .
git commit -m "Fix critical issue in production"

# hotfix 브랜치를 main에 병합
git checkout main
git merge --no-ff hotfix/1.0.1

# hotfix 버전 태그 추가
git tag -a 1.0.1 -m "Hotfix for version 1.0.1"

# hotfix 브랜치를 develop에 병합
git checkout develop
git merge --no-ff hotfix/1.0.1

# 사용이 끝난 핫픽스 브랜치 삭제
git branch -d hotfix/1.0.1

전체적인 Git Flow 설명

  1. 기능 개발: 각 기능은 develop에서 분기된 feature 브랜치에서 독립적으로 개발됩니다. 완료되면 다시 develop에 병합합니다.
  2. 릴리스 준비: 모든 기능이 개발되고 통합되면, release 브랜치를 생성하여 마지막 테스트와 버그 수정을 진행합니다. 이후, main에 병합하여 프로덕션에 배포합니다.
  3. 핫픽스: 프로덕션에서 발견된 긴급한 버그는 hotfix 브랜치를 생성하여 빠르게 수정한 후, main과 develop에 모두 반영합니다.

결론

Git Flow는 브랜치 전략 중에서도 복잡한 프로젝트를 체계적으로 관리하는 데 매우 유용한 방법입니다. 이 전략을 통해 기능 개발, 릴리스 준비, 그리고 프로덕션 버그 수정을 명확하게 구분하고, 각각의 작업을 독립적인 브랜치에서 처리할 수 있습니다. 이를 통해 코드의 안정성을 유지하고, 여러 명의 개발자가 협업하는 환경에서 충돌을 최소화할 수 있습니다.

하지만 Git Flow는 관리해야 할 브랜치가 많아지기 때문에, 대규모 프로젝트에서는 브랜치 관리가 복잡해질 수 있고, 긴 릴리스 주기를 요구하는 경우에만 적합할 수 있습니다. 빠른 배포를 목표로 하는 CI/CD 환경에서는 다른 브랜치 전략을 고려하는 것이 더 적합할 수 있습니다.

결론적으로, Git Flow는 명확한 릴리스 주기가 있는 프로젝트에서는 매우 효율적으로 작동하지만, 각 프로젝트의 특성에 맞는 브랜치 전략을 선택하는 것이 중요합니다.