개발 도구
Git 브랜치 전략 완벽 가이드 — GitHub Flow와 Git Flow 비교 및 선택 방법
팀 규모와 배포 방식에 따라 맞는 Git 브랜치 전략이 다르다. 단순하고 빠른 GitHub Flow, 체계적인 Git Flow의 차이와 각각 어떤 상황에서 써야 하는지 정리했다.
- ·Git Flow: Vincent Driessen이 2010년 제안, develop/release/hotfix 브랜치 체계
- ·GitHub Flow: GitHub 팀이 사용하는 단순화된 브랜치 전략, main 브랜치와 feature 브랜치만 사용
- ·Trunk-Based Development: Google, Facebook이 쓰는 방식, 모두 main에 자주 머지
- ·Protected branch: main 브랜치에 직접 push를 막고 PR을 통해서만 머지하도록 강제
사이드 프로젝트에서 Git Flow를 도입했다가 develop, release, hotfix 브랜치를 관리하는 오버헤드가 너무 커서 결국 GitHub Flow로 전환했다. 혼자 또는 소수 팀이 빠르게 배포하는 환경에서는 GitHub Flow가 훨씬 현실적이었다. 반면 회사에서 정기 릴리즈 주기가 있는 프로젝트에서는 Git Flow의 release 브랜치가 QA 기간 동안 main을 안정적으로 유지하는 데 실제로 도움이 됐다.
Git 브랜치 전략이 필요한 이유
Git 브랜치 전략이 팀 협업에 필요한 이유
Git은 브랜치를 자유롭게 만들고 합칠 수 있는 강력한 도구지만, 팀이 어떤 규칙 없이 브랜치를 사용하면 혼란이 생긴다. 누가 어떤 브랜치에서 작업하는지, 배포 가능한 코드가 어느 브랜치에 있는지, 긴급 수정은 어떻게 반영하는지에 대한 합의가 없으면 충돌이 잦아지고 배포가 불안해진다. 브랜치 전략은 이 문제를 해결하는 팀의 규칙이다. 언제 브랜치를 만들고, 어떻게 이름을 짓고, 어느 브랜치로 머지하고, 어느 브랜치에서 배포하는지를 약속해두는 것이다. 좋은 브랜치 전략은 새 기능 개발 중에도 프로덕션 배포가 가능하고, 버그 수정이 개발 중인 기능과 독립적으로 이루어지며, 코드 리뷰가 자연스럽게 파이프라인에 포함된다. 브랜치 전략이 없을 때 자주 생기는 문제가 있다. 급한 버그 수정을 하려는데 개발 중인 반완성 코드가 main에 섞여 있어서 수정만 따로 배포할 수 없는 상황이다. 처음부터 브랜치 전략을 정해두면 이런 상황을 방지할 수 있다.
GitHub Flow와 Git Flow 이해하기
GitHub Flow — 단순하고 빠른 Git 브랜치 전략
GitHub Flow는 단순함이 핵심이다. main 브랜치 하나와 feature 브랜치만 사용한다. 새 작업을 시작할 때 main에서 feature 브랜치를 만들고 작업한다. 작업이 끝나면 Pull Request를 열어 팀원의 리뷰를 받고 main으로 머지한다. 머지되면 즉시 배포한다. main 브랜치는 항상 배포 가능한 상태여야 한다는 것이 이 전략의 핵심 전제다. 규칙이 적어서 팀원들이 쉽게 이해하고 따를 수 있다. 기능 개발을 완료하면 바로 배포로 이어지기 때문에 배포 주기가 짧고 빠르다. CI/CD가 잘 갖춰져 있어서 main에 머지되면 자동으로 테스트와 배포가 이루어지는 환경에 이상적이다. 단점은 복잡한 릴리즈 관리가 어렵다는 점이다. 여러 기능을 동시에 개발하다가 일부만 선택해서 릴리즈하거나, QA 기간 동안 새 기능 추가를 막으면서 버그만 수정하는 상황을 처리하기 어렵다. 혼자 하는 프로젝트나 소수 팀이 빠르게 배포하는 웹 서비스에서는 GitHub Flow가 가장 현실적이고 오버헤드가 적은 선택이다.
Git Flow — 체계적인 브랜치 관리 전략과 각 브랜치의 역할
Git Flow는 main, develop, feature, release, hotfix 다섯 가지 브랜치 유형을 사용한다. main 브랜치는 항상 프로덕션 배포 상태다. develop 브랜치는 다음 릴리즈를 위한 통합 브랜치다. 새 기능은 develop에서 feature 브랜치를 분기해서 개발하고, 완료되면 develop으로 머지한다. 릴리즈 준비가 되면 develop에서 release 브랜치를 만든다. release 브랜치에서는 새 기능 추가 없이 버그 수정과 버전 번호 변경만 한다. QA가 완료되면 release를 main과 develop 양쪽에 머지하고 main에 버전 태그를 단다. 프로덕션 버그는 main에서 hotfix 브랜치를 만들어 수정하고 main과 develop에 동시에 반영한다. 이 구조는 정기적인 릴리즈 주기가 있는 제품에 적합하다. QA 기간 동안 develop은 계속 진행되고, release 브랜치에서는 안정화 작업만 한다. 버전 관리와 릴리즈 노트가 명확하게 구분된다. 단점은 브랜치 수가 많아서 관리 부담이 크고, 빠른 배포보다 안정적인 릴리즈를 우선시하는 구조라 현대 DevOps 환경에서는 느리게 느껴질 수 있다.
Git 브랜치 전략 선택과 실용 설정
팀 상황에 맞는 Git 브랜치 전략을 선택하는 방법
어떤 브랜치 전략이 맞는지는 팀 규모, 배포 빈도, 릴리즈 방식에 따라 달라진다. 혼자 또는 2~3명이 개발하고 하루에도 여러 번 배포하는 사이드 프로젝트나 스타트업 초기 제품이라면 GitHub Flow가 적합하다. 브랜치가 단순하고 PR 단위로 코드 리뷰가 이루어지면서 배포 속도를 잃지 않는다. 팀이 크거나 정기 릴리즈 주기가 있는 제품, 앱 스토어 심사처럼 배포 시점을 조율해야 하는 경우라면 Git Flow가 도움이 된다. release 브랜치를 통해 기능 개발과 릴리즈 안정화를 분리할 수 있다. 어떤 전략을 선택하든 공통적으로 지켜야 할 원칙이 있다. main 브랜치에 직접 push는 하지 않는다. Protected branch 설정으로 PR 없이는 main에 머지되지 않도록 강제하면 좋다. 브랜치 이름은 feature/, bugfix/, hotfix/ 같은 접두사로 용도를 명확히 한다. 오래된 머지된 브랜치는 정기적으로 정리한다. 처음 팀에서 브랜치 전략을 정할 때는 단순하게 시작하고 문제가 생기면 규칙을 추가하는 방식이 복잡한 전략을 처음부터 도입하는 것보다 실용적이다.
GitHub에서 Git 브랜치 전략을 실행하는 보호 설정과 PR 규칙
브랜치 전략은 규칙만 정해서는 안 되고 도구로 강제해야 일관성이 유지된다. GitHub에서는 Branch Protection Rules를 설정해 main 브랜치에 직접 push를 막고 PR을 통해서만 머지되도록 강제할 수 있다. 저장소 Settings → Branches → Add branch protection rule에서 설정한다. Require a pull request before merging을 활성화하면 PR 없이 main에 push할 수 없다. Require status checks to pass를 활성화하면 GitHub Actions CI가 통과해야 머지가 가능하다. Require approvals를 1 이상으로 설정하면 최소 한 명의 리뷰 승인이 필요하다. 혼자 하는 프로젝트라도 이 규칙을 걸어두면 실수로 main에 직접 push하는 사고를 막을 수 있다. PR 템플릿을 .github/pull_request_template.md 파일로 만들어두면 PR을 열 때마다 자동으로 체크리스트와 설명 형식이 채워진다. 어떤 변경을 왜 했는지 적는 습관이 자연스럽게 생기고 리뷰어가 맥락을 파악하기 쉬워진다. 이 설정들을 처음에 갖춰두면 팀이 커져도 코드 품질과 배포 안정성을 유지하는 기반이 된다.
자주 묻는 질문
Git Flow와 GitHub Flow 중 어느 것을 처음에 써야 하나요?+
처음에는 GitHub Flow를 추천합니다. 규칙이 단순해서 팀원 모두가 쉽게 따를 수 있고, 나중에 정기 릴리즈가 필요해지면 그때 Git Flow 요소를 점진적으로 도입할 수 있습니다.
feature 브랜치 이름은 어떻게 짓는 게 좋은가요?+
feature/기능명, bugfix/이슈번호-설명, hotfix/버그명 패턴이 많이 쓰입니다. GitHub Issues나 Jira 티켓 번호를 포함하면 브랜치와 이슈를 연결하기 쉽습니다. 예: feature/123-user-login, bugfix/456-null-pointer-error.
Squash merge, Merge commit, Rebase merge 중 어떤 걸 써야 하나요?+
Squash merge는 feature 브랜치의 커밋을 하나로 합쳐서 머지합니다. main 브랜치 히스토리가 깔끔해지지만 개별 커밋 기록이 사라집니다. 팀의 커밋 작성 습관이 일정하지 않다면 Squash가 좋은 선택입니다. Rebase는 히스토리를 선형으로 유지하지만 복잡도가 높습니다.
main 브랜치에 실수로 직접 push했을 때 되돌리는 방법이 있나요?+
git revert로 해당 커밋을 되돌리는 커밋을 만드는 게 안전합니다. git reset --hard는 이미 push된 커밋을 지우기 때문에 팀원들 로컬 저장소와 충돌이 생깁니다. 다음부터는 Branch Protection Rules를 설정해서 직접 push 자체를 막는 게 좋습니다.
관련 글
GitHub Actions로 Node.js CI/CD 파이프라인을 구성하는 방법 — 빌드부터 자동 배포까지
Jenkins 없이 GitHub 저장소 안에서 CI/CD를 완결하고 싶다면 GitHub Actions가 가장 빠른 선택이다. workflow 파일 작성부터 Secrets 관리, SSH 배포까지 순서대로 정리했다.
Jenkins GitHub Webhook 트리거 완벽 가이드 — push 후 즉시 빌드를 시작하는 방법
pollSCM 대신 GitHub Webhook을 연결하면 push 직후 Jenkins 빌드가 시작된다. Jenkins Webhook 수신 설정부터 GitHub 등록, Jenkinsfile 트리거 선언까지 순서대로 정리했다.
Jenkins 빌드 스케줄러 완벽 가이드 — Jenkinsfile에 cron 트리거 추가하는 방법
Jenkins UI에서 직접 관리하던 파이프라인을 Jenkinsfile로 전환하고, cron 트리거로 매일 자동 빌드를 구성하는 방법을 정리했다.