[GIT] Git Flow - 가장 쉬운 깃 브랜치 전략 (생애 첫 기술 발표 영상)

1. Git Flow란 무엇인가?

Git Flow는 소프트웨어 개발 프로세스에서 효율적인 브랜치 관리와 협업을 돕는 브랜치 전략입니다. 개발, 테스트, 배포 등의 단계에서 코드의 안정성을 확보하고, 여러 개발자 간 협업을 체계적으로 할 수 있게 해줍니다. Git Flow는 feature, develop, release, hotfix, main(또는 prod)와 같은 브랜치 구조를 사용하여 명확한 워크플로우를 제공합니다.

2. Git Flow의 주요 브랜치 규칙

Git Flow는 다섯 가지 주요 브랜치로 작업을 나누며, 각 브랜치는 특정 목적과 규칙을 가지고 있습니다.

1) main 브랜치 (prod)

• 목적: 운영 서버에 배포되는 안정적인 코드를 관리합니다.
• 규칙: main에는 항상 릴리스된 코드만 포함되어야 하며, 직접 작업이 아닌 다른 브랜치(release, hotfix)에서 병합됩니다.

2) develop 브랜치

• 목적: 배포 준비를 위한 다음 릴리스 버전을 개발합니다. 새로운 기능이 모두 develop에서 통합되고 테스트됩니다.
• 규칙: develop에는 반드시 prod에 배포할 예정인 코드만 병합해야 합니다. 아직 검증되지 않은 기능이나 임시 코드가 들어가면 안 됩니다.

3) feature 브랜치

• 목적: 개별 기능 또는 버그 수정을 개발합니다.
• 규칙: 항상 develop 브랜치에서 파생되어 개발하고, 완료되면 다시 develop에 병합합니다. 브랜치 이름은 feature/로 시작하며, 기능을 설명하는 이름이나 이슈 번호를 붙여 일관성을 유지합니다.
  • 예: feature/DS-212, feature/user-authentication

4) release 브랜치

• 목적: 배포 준비가 완료된 코드를 마지막으로 검증하고, 버그 수정 및 안정화 작업을 합니다.
• 규칙: develop 브랜치에서 생성하며, 모든 검증 작업이 끝나면 main과 develop에 병합합니다. 브랜치 이름은 release/로 시작하고 버전 번호를 포함합니다.
  • 예: release/v1.0.0

5) hotfix 브랜치

• 목적: 운영 중인 main에서 긴급한 버그를 수정합니다.
• 규칙: main 브랜치에서 파생되어 작업하고, 수정이 완료되면 main과 develop에 모두 병합합니다. 브랜치 이름은 hotfix/로 시작합니다.
  • 예: hotfix/loginError, hotfix/payment-issue

3. 왜 Git Flow를 지켜야 하는가?

1. 명확한 워크플로우: 각 브랜치의 역할과 작업 흐름이 명확하게 구분되므로, 협업 시 발생할 수 있는 혼란을 방지합니다.
2. 코드 안정성 확보: develop과 release를 통한 검증 프로세스를 거치므로, 배포되는 코드의 안정성을 보장할 수 있습니다.
3. 독립적인 기능 개발: feature 브랜치를 통해 독립적으로 기능을 개발하고 테스트할 수 있습니다. 다른 기능에 영향을 주지 않고 필요한 기능만 선택적으로 배포할 수 있습니다.
4. 긴급 대응: hotfix 브랜치를 통해 운영 환경에서 발생한 긴급한 문제를 신속하게 해결하고, 배포할 수 있습니다.

4. Git Flow 관리 방법

Git Flow를 제대로 관리하기 위해서는 몇 가지 원칙과 규칙을 따라야 합니다.

1) 브랜치의 명확한 규칙 설정

• 브랜치 이름에 접두사를 붙여 역할을 명확히 구분합니다 (feature/, hotfix/, release/).
• 일관성 있는 브랜치 네이밍 규칙은 작업의 목적과 상태를 쉽게 파악할 수 있도록 돕습니다.

2) 병합 전략

• feature → develop 병합: 기능 개발이 완료되면 develop 브랜치에 병합하여 테스트합니다.
• develop → release 병합: 배포 준비가 완료되면 release 브랜치를 만들어 최종 검증을 진행합니다.
• release → main 병합: release 브랜치의 최종 검증이 완료되면 main에 병합하고, 배포합니다. 동시에 release 브랜치를 develop에도 병합하여 최신 상태를 유지합니다.
• hotfix → main 및 develop 병합: 운영 환경의 긴급한 버그를 수정할 때는 hotfix 브랜치를 만들어 작업하고, 수정이 완료되면 main과 develop에 병합하여 두 브랜치의 싱크를 유지합니다.

3) 커밋 관리

• 커밋 메시지를 명확하게 작성하여 변경 사항을 추적할 수 있도록 합니다. 예를 들어, 이슈 번호와 함께 "Fix login error (issue #123)"와 같이 작성합니다.
• 기능 단위로 커밋: 각 커밋은 가능한 작은 기능 단위로 작성하여, 필요 시 선택적으로 병합하거나 되돌릴 수 있도록 합니다.

4) CI/CD와 연계

• Continuous Integration/Continuous Deployment (CI/CD) 도구를 활용하여 develop, release, main 브랜치에 병합될 때 자동으로 테스트를 실행하고, 코드 품질을 검증합니다. 이를 통해 버그를 조기에 발견하고 배포 안정성을 확보할 수 있습니다.

5. Git Flow의 한계와 보완점

• 복잡성: 브랜치가 많아질 수 있으므로, 브랜치 관리가 복잡해질 수 있습니다. 이를 보완하려면 팀원 간의 명확한 규칙과 커뮤니케이션이 중요합니다.
• 동기화: develop과 main 브랜치의 싱크를 주기적으로 맞춰야 하며, 특히 긴급 수정(hotfix) 후에는 이 작업을 꼭 수행해야 합니다.

6. 결론

Git Flow는 소프트웨어 개발의 모든 단계에서 발생하는 다양한 요구 사항을 충족하기 위한 체계적인 브랜치 전략입니다. 이 방식의 핵심은 각 브랜치의 역할을 명확히 규정하고, 이를 엄격히 지키는 것입니다. 이렇게 함으로써 협업 과정에서 혼란을 줄이고, 안정적인 코드를 배포할 수 있습니다.

Git Flow를 통해 브랜치 관리가 체계적으로 이루어지면, 팀 전체의 개발 효율성이 높아지고, 배포 시 발생할 수 있는 위험을 최소화할 수 있습니다. 규칙을 지키는 것은 단순히 브랜치 관리의 편의를 넘어, 소프트웨어 품질을 높이는 가장 효과적인 방법입니다.