2026-01-18 | 6 min read | 173 | git github flow 실습 고급

4-2. Git의 workflow: GitHub Flow 실습

1. GitHub Flow의 개요

GitHub Flow는 Git을 기반으로 하는 단순하고 가벼운 브랜치 전략입니다. 이는 특히 협업 환경에서 빠른 릴리스 주기를 원하는 팀에게 적합합니다. Gitflow와는 달리, GitHub Flow는 복잡한 브랜치 구조를 피하고, 단순하고 예측 가능한 워크플로우를 제공합니다. 이 전략의 핵심은 "주요 브랜치(main)"와 "피처 브랜치(feature branches)"를 중심으로 진행됩니다.

1) GitHub Flow의 배경

GitHub Flow는 GitHub 플랫폼의 개발 철학을 반영하여 탄생했습니다. GitHub는 잦은 배포와 빠른 피드백 루프를 통해 개발 속도를 높이는 것을 중요하게 여깁니다. Gitflow는 더 정형화된 릴리스 관리를 제공하지만, 잦은 병합과 릴리스 준비 과정은 때때로 개발 속도를 늦출 수 있습니다. 이에 비해 GitHub Flow는 더 단순한 접근 방식을 통해 개발팀이 빠르게 기능을 출시하고, 지속적으로 통합하며, 더 많은 실험을 할 수 있도록 설계되었습니다.

2) GitHub Flow의 특징

GitHub Flow는 다음과 같은 특징을 갖습니다.

간결함: 주요 브랜치인 main 외에, 각 기능별로 생성되는 feature branches를 활용하여 브랜치 구조가 단순합니다.
지속적인 통합: 작은 단위의 변경 사항을 자주 통합하여, 충돌을 최소화하고 문제 발생 시 빠르게 대응할 수 있습니다.
빠른 배포: 잦은 배포를 통해 사용자 피드백을 빠르게 수집하고, 기능을 개선할 수 있습니다.
Pull Request 중심: 모든 변경 사항은 Pull Request를 통해 코드 검토, 토론 및 통합됩니다.
단일 릴리스: 별도의 릴리스 브랜치가 없이, main 브랜치 자체가 곧 배포 가능한 상태를 유지합니다.

2. GitHub Flow의 핵심 원리

GitHub Flow는 몇 가지 핵심 원리를 따릅니다. 각 단계별로 자세히 살펴보겠습니다.

1) `main` 브랜치

main 브랜치는 항상 배포 가능한 상태를 유지합니다. 이는 가장 중요한 원칙 중 하나입니다. 어떤 시점에도, main 브랜치의 코드는 사용자가 사용할 수 있는 제품의 최신 버전을 나타내야 합니다. 이 브랜치에는 버그 수정, 새로운 기능의 통합 등 모든 변경 사항이 merge됩니다.

2) Feature Branches

새로운 기능을 개발하거나, 버그를 수정할 때는 main 브랜치에서 분기된 feature branches를 사용합니다. 각 feature branch는 하나의 기능을 구현하거나, 하나의 버그를 수정하는 데 집중해야 합니다. 브랜치 이름은 해당 기능이나 버그의 내용을 명확하게 반영해야 합니다 (예: feature/user-authentication, bugfix/login-issue).

3) Pull Request (PR)

기능 개발이 완료되면, 해당 feature branch를 main 브랜치에 병합하기 위해 Pull Request를 생성합니다. PR은 코드 리뷰, 토론, 그리고 코드 변경 사항의 통합을 위한 중심지 역할을 합니다.

4) 코드 리뷰

PR이 생성되면, 다른 개발자는 해당 변경 사항을 검토합니다. 코드 리뷰를 통해 코드 품질을 높이고, 잠재적인 문제를 미리 발견하며, 다른 개발자들과 지식을 공유할 수 있습니다. 리뷰어는 코드의 가독성, 효율성, 그리고 기능 구현의 적절성을 평가합니다.

5) 통합 및 배포

코드 리뷰가 완료되고, 모든 검토자가 승인하면, 해당 feature branch는 main 브랜치에 병합됩니다. main 브랜치에 병합되면, 해당 변경 사항은 즉시 배포 가능합니다.

6) 릴리스

GitHub Flow에서는 별도의 릴리스 브랜치를 생성하지 않습니다. main 브랜치가 항상 릴리스 가능한 상태를 유지하기 때문입니다. 배포는 main 브랜치의 최신 코드를 프로덕션 환경에 적용하는 것을 의미합니다.

GitHub Flow 핵심 원리 설명 뒤

graph TD
    A[main] --> B{feature/feature-name}
    B --> C{Pull Request}
    C --> D{Code Review}
    D -- Approve --> E[Merge to main]
    E --> F[Deploy]
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#ccf,stroke:#333,stroke-width:2px
    style D fill:#ccf,stroke:#333,stroke-width:2px
    style E fill:#ccf,stroke:#333,stroke-width:2px

3. GitHub Flow 실습

GitHub Flow를 실제로 적용하는 실습을 통해 이해도를 높여보겠습니다. 예시 프로젝트는 간단한 웹사이트의 기능 추가 및 수정으로 구성됩니다.

1) 저장소 설정 및 초기 브랜치 생성

새로운 GitHub 저장소 생성: GitHub에서 새로운 저장소를 생성하고, README.md 파일을 초기 커밋으로 추가합니다.
로컬 저장소 복제: 로컬 환경에서 GitHub 저장소를 복제합니다.
main 브랜치 확인: main 브랜치가 로컬 저장소의 기본 브랜치인지 확인합니다. ( git branch 명령어를 사용하여 확인)

2) Feature Branch 생성 및 기능 구현

Feature Branch 생성: 새로운 기능 (about 페이지)을 개발하기 위해 main 브랜치에서 feature/about-page 브랜치를 생성합니다. bash git checkout -b feature/about-page
기능 구현: about 페이지를 위한 HTML 파일 (about.html)을 생성하고, 내용을 작성합니다.

html <!DOCTYPE html> <html> <head> <title>About Us</title> </head> <body> <h1>About Us</h1> <p>This is the about page content.</p> </body> </html> 3. 변경 사항 추가 및 커밋: 변경 사항을 스테이징하고 커밋합니다. bash git add about.html git commit -m "feat: Add about page"

3) Pull Request 생성 및 코드 리뷰

Feature Branch Push: 로컬 feature/about-page 브랜치를 원격 저장소에 푸시합니다. bash git push origin feature/about-page
Pull Request 생성: GitHub 웹 인터페이스에서 feature/about-page 브랜치에 대한 Pull Request를 생성합니다.
코드 리뷰: 동료 개발자에게 코드 리뷰를 요청하고, 리뷰어는 변경 사항을 검토합니다. 필요한 경우, 코드 수정 사항에 대한 피드백을 주고받습니다.
코드 수정 (필요시): 리뷰어의 피드백을 반영하여 코드를 수정하고, 다시 커밋하고 푸시합니다.
Pull Request Merge: 모든 검토가 완료되고, 리뷰어가 승인하면 Pull Request를 main 브랜치에 merge합니다.

mermaid graph TD A[feature/about-page] --> B(Create Pull Request) B --> C{Code Review} C -- Approve --> D(Merge Pull Request) D --> E[main]

4) 배포

main 브랜치 Pull: 로컬의 main 브랜치로 전환하고, 원격 저장소의 main 브랜치를 pull하여 최신 변경 사항을 가져옵니다. bash git checkout main git pull origin main
배포: main 브랜치의 코드를 프로덕션 서버에 배포합니다. (예시에서는 수동 배포를 가정). 웹 서버에 about.html 파일이 제대로 배포되었는지 확인합니다.

5) 버그 수정

Bugfix Branch 생성: 버그 수정 (예: 헤더 스타일 오류)을 위해 main 브랜치에서 bugfix/header-style 브랜치를 생성합니다. bash git checkout -b bugfix/header-style
버그 수정: 헤더 스타일 문제를 수정합니다.
변경 사항 추가 및 커밋: 변경 사항을 스테이징하고 커밋합니다. bash git add style.css git commit -m "fix: Header style issue"
Pull Request 생성 및 병합: 위와 동일한 과정을 반복하여 bugfix/header-style 브랜치를 main 브랜치에 merge하고, 배포합니다.

4. GitHub Flow의 장점과 단점

GitHub Flow는 장점과 단점을 모두 가지고 있습니다. 상황에 맞는 전략을 선택하는 것이 중요합니다.

1) 장점

단순성: 이해하기 쉽고 사용하기 쉬운 워크플로우입니다.
빠른 개발: 잦은 배포와 지속적인 통합을 통해 개발 속도를 높입니다.
유연성: 다양한 프로젝트에 적용 가능합니다.
쉬운 협업: Pull Request를 통해 코드 리뷰를 쉽게 진행할 수 있습니다.
지속적인 배포: main 브랜치가 항상 배포 가능한 상태를 유지하므로, 릴리스 프로세스가 간소화됩니다.

2) 단점

작은 릴리스: GitHub Flow는 작은 변경 사항에 적합하므로, 대규모 기능 개발에는 적합하지 않을 수 있습니다.
병합 충돌: 잦은 병합은 병합 충돌을 발생시킬 수 있습니다.
단일 브랜치: main 브랜치만 존재하므로, 다양한 릴리스 전략을 지원하지 않습니다.
테스트 중요성: main 브랜치가 항상 배포 가능한 상태를 유지해야 하므로, 철저한 테스트가 필수적입니다.

5. GitHub Flow 사용 시 주의사항

GitHub Flow를 효율적으로 사용하기 위해서는 다음과 같은 사항에 유의해야 합니다.

1) 코드 리뷰의 중요성

코드 리뷰는 GitHub Flow의 핵심 요소입니다. 코드 리뷰를 통해 코드 품질을 높이고, 버그를 조기에 발견하며, 개발자 간의 지식을 공유할 수 있습니다.

2) 작은 단위의 커밋

작은 단위의 커밋은 변경 사항을 쉽게 이해하고, 코드 리뷰를 효율적으로 진행하는 데 도움이 됩니다.

3) 잦은 통합

잦은 통합은 병합 충돌을 줄이고, 문제 발생 시 빠르게 대응할 수 있게 해줍니다.

4) 자동화된 테스트

자동화된 테스트는 코드 변경으로 인한 문제를 사전에 방지하는 데 필수적입니다. 모든 변경 사항이 main 브랜치에 병합되기 전에 테스트를 통과해야 합니다.

5) 명확한 커밋 메시지

명확하고 구체적인 커밋 메시지는 코드 변경 사항을 이해하고, 추후에 코드 변경 이력을 파악하는 데 도움이 됩니다.

6. 결론

GitHub Flow는 단순하면서도 강력한 브랜칭 전략입니다. 잦은 배포와 빠른 피드백 루프를 통해 개발 속도를 높일 수 있으며, 팀의 협업 효율성을 향상시킬 수 있습니다. 하지만, 대규모 프로젝트나 복잡한 릴리스 전략이 필요한 경우에는 다른 브랜칭 전략을 고려하는 것이 좋습니다. GitHub Flow의 장점과 단점을 잘 이해하고, 프로젝트의 특성에 맞게 적용하는 것이 중요합니다. GitHub Flow를 효과적으로 사용하기 위한 실습과 주의사항을 숙지하여, 개발 생산성을 높이는 데 활용하시기 바랍니다.