Git 워크플로
목차
Git 워크플로
Git 명령을 배우는 것과 팀이 Git 을 어떻게 운영하는지 배우는 것은 다릅니다. 이 글은 브랜치 전략 · 커밋 메시지 규약 · 버전 표기 규약 · PR 리뷰 · 훅 도구.
1. Git 에 대한 이야기
Linus Torvalds 가 2005 년에 만든 분산 버전관리 시스템. 같은 도구라도 팀이 합의한 운영 방식 (브랜치 전략 · 머지 정책 · 메시지 규약) 에 따라 결과는 크게 달라집니다.
2. 브랜치 전략
대표적인 네 갈래.
Trunk-Based Development — Paul Hammant 가 정리한 trunkbaseddevelopment.com. "단일 브랜치 trunk 에서 협업하고 장수 브랜치를 만들지 않는" 모델. 작은 팀은 직접 trunk 로 커밋, 큰 팀은 짧은 수명 (보통 하루 ~ 며칠) 의 피처 브랜치 + PR. 미완성 기능은 feature flag 로 가림. Google 의 거대 모노레포가 대표 사례.
Git Flow — Vincent Driessen 이 2010 년 블로그 글 "A successful Git branching model" 에서 정리. main · develop · feature/* · release/* · hotfix/* 다섯 종류의 브랜치. 정해진 출시 주기를 가진 패키지 소프트웨어에 어울리고, 지속 배포 환경에서는 무겁다는 평이 굳어짐.
GitHub Flow — GitHub 가 2011 년 즈음 정착시킨 단순 모델. main 한 줄과 짧은 피처 브랜치, PR 으로 머지, 머지 즉시 배포. 웹 서비스 · SaaS 에서 흔함.
GitLab Flow — GitLab 이 정리한 변형. GitHub Flow 에 환경별 브랜치 (production · pre-production) 또는 릴리스 브랜치를 더해, 배포 시점을 분리해야 하는 환경에 맞춤.
각 모델이 어울리는 환경은 다름. 출시 주기 · 배포 자동화 수준 · 팀 규모에 따라 적합한 쪽이 달라집니다.
3. 커밋 메시지 규약
Conventional Commits 1.0.0 (conventionalcommits.org) 이 가장 널리:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
대표 type — feat (새 기능, semver MINOR) · fix (버그 수정, PATCH) · docs · style · refactor · perf · test · build · chore · ci. 호환 깨짐은 feat!: 또는 footer 의 BREAKING CHANGE: 로 표시 (MAJOR).
이 규약을 지키면 changelog 자동 생성 · semver 자동 산정 도구 (semantic-release · changesets) 와 자연스럽게 연결.
4. 버전 표기
Semantic Versioning 2.0.0 (semver.org, Tom Preston-Werner) 의 형식 — MAJOR.MINOR.PATCH:
- MAJOR — 비호환 API 변경.
- MINOR — 호환되는 기능 추가.
- PATCH — 호환되는 버그 수정.
1.2.3-alpha.1 같은 사전 릴리스, 1.2.3+build.42 같은 빌드 메타데이터도 형식에 포함. 0.y.z 는 초기 개발용으로 호환성 약속이 없음.
CalVer (2024.10.0 처럼 날짜 기반) 같은 다른 표기 규약도. 라이브러리는 SemVer, 애플리케이션은 CalVer 가 자주.
5. PR 리뷰
GitHub · GitLab · Bitbucket 의 PR / MR 은 코드 변경을 검토 단위로 모아 두는 장치. 흔히 권장되는 관습:
- 작은 PR — 한 PR 이 한 가지 의도만 담을 때 리뷰가 빠르고 회귀가 적다는 평가가 흔함.
- CODEOWNERS — 디렉터리별 자동 리뷰어 지정. GitHub · GitLab 모두 지원.
- 비동기 리뷰 — 시차가 있는 팀에서는 즉시 답변이 어려움. 리뷰 응답 시한 · 블로커 표시 (
Request changesvsComment) 를 합의. - 머지 정책 — squash / rebase / merge commit 셋 중 하나. 히스토리 모양과 changelog 자동화에 영향.
6. Git 훅 도구
훅은 커밋 · 푸시 같은 시점에 스크립트를 끼우는 Git 의 내장 기능 (.git/hooks/). 팀 단위로 공유하려면 도구가 필요.
- Husky (Node) —
package.json·.husky/로 훅 관리. JS 생태계의 표준 격. - lint-staged (Node) — 스테이지된 파일만 골라 린터 / 포매터 실행. Husky 와 함께.
- lefthook (Evil Martians, Go) — 언어 비종속. 단일 바이너리.
- pre-commit (pre-commit.com, Python) — 다언어 훅 매니저.
.pre-commit-config.yaml에 도구 목록. Python · Go 생태계에서 흔함.
7. 자주 쓰는 모양
# 짧은 피처 브랜치 + PR (GitHub Flow)
git switch -c feat/login-form
# ... 작업 ...
git add -p
git commit -m "feat(auth): add email login form"
git push -u origin feat/login-form
gh pr create --fill # GitHub CLI
.gitignore 와 별개로, 큰 바이너리는 Git LFS 가 적합 (git lfs track "*.psd").
CODEOWNERS 예:
# 경로 소유자
/apps/web/ @org/frontend
/services/api/ @org/backend
*.md @org/docs
pre-commit 설정 예:
# .pre-commit-config.yaml
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.6.9
hooks:
- id: ruff
- id: ruff-format
8. 자주 걸리는 자리
git push --force 가 공유 브랜치를 덮어쓰는 사고 — --force-with-lease 가 한 단계 안전.
머지 vs 리베이스 — 정책을 팀이 합의하지 않으면 한 사람의 리베이스가 다른 사람의 로컬 히스토리를 헝클 수 있음.
큰 PR — 리뷰가 형식적으로 끝나기 쉬움. 커밋 단위와 PR 단위 둘 다 작게 유지하는 편이 결함 적발에 유리.
BREAKING CHANGE: 푸터 누락 — feat! 만 적으면 자동 changelog 도구가 제목 외 본문을 비워 두는 경우.
윈도우 줄바꿈 (core.autocrlf) 통일 안 됨 — diff 가 전부 줄바꿈으로 채워지는 사고. .gitattributes 로 파일 유형별 정책 명시.
하고픈 말
Git 의 명령보다 팀의 운영 방식이 결과를 좌우합니다. Trunk-Based 또는 GitHub Flow 의 단순함 + Conventional Commits + Semantic Versioning + 작은 PR + 명확한 머지 정책 다섯이 함께 있을 때 협업 마찰이 가장 작은 자리. 커밋 메시지의 일관성이 changelog · 릴리스 자동화의 토대.
Next
- gradle
- editor-setup
Pro Git Book · Conventional Commits 1.0.0 · Semantic Versioning 2.0.0 · Trunk-Based Development · GitHub Flow Guide · Vincent Driessen Git Flow (2010) · GitLab Flow · pre-commit.com · Google Engineering Practices Code Review 를 참고합니다.