GitHub Flow, Trunk-Based, GitFlow

Workflow 선택, 그 선택이 모든 걸 결정

'Workflow' 는 부드럽게 들리지만 branch 수명, release 주기, conflict 빈도, CI 구조까지 결정. 패턴 셋이 지배적이고 각자 다른 팀에 맞아. 실수: 섞기 — 절반은 GitFlow 인 척, 절반은 trunk-based 인 척, main 에 양립 불가 두 모양으로 commit 도착. 하나 골라, 문서화, 플랫폼 설정으로 강제.

GitHub Flow 가 가장 단순: main 은 항상 배포 가능, 모든 변경은 main 분기 짧은 feature branch 에서, PR 열기, 리뷰, merge 또는 rebase 로 land, 배포. 장기 develop / release branch 없음. 연속 배포 팀 (대부분 modern web/SaaS) 이 사용 — branch → PR → merge → 배포 사이클이 시간 단위. 암묵적 제약: 진짜 CI/CD 작동해야 함, 아니면 'main 배포 가능' 은 거짓.

Trunk-Based Development 가 더 나아가: 대부분 엔지니어가 main 에 직접 commit (또는 시간 단위 PR), feature branch 드물고, 미완성 기능은 feature flag 뒤에. 하루 여러 번 release. 매우 빠른 피드백 최적화 팀 (Google, Spotify 규모) 사용. 강한 feature flag, 포괄적 test, 'broken main 모두 막음 — 수분 내 수정' 의 문화적 commitment 필요.

GitFlow 가 가장 무거움: main 은 production only, develop 이 통합 branch, feature branch 는 develop 에서, release branch 가 main 의 tagged release 전 안정화, hotfix branch 는 main 에서 바로 + 둘 다로 merge. Versioned product (데스크톱 앱, semver 있는 라이브러리, 규제 소프트웨어) ship 하는 팀 사용. 복잡성이 reproducible release line 대신 overhead — 연속 배포엔 안 맞아.

Code

GitHub Flow — daily 루틴·bash

# 작업 시작:
git switch main
git pull --ff-only

# Main 에서 분기, 작업, push:
git switch -c feature/login-redesign
# ... 편집, commit ...
git push -u origin feature/login-redesign

# PR 열기 (gh CLI 또는 web), 리뷰, land:
gh pr create --base main --title "Redesign login"
# 승인 + CI 녹색 후:
gh pr merge --squash --delete-branch

GitFlow 골격 (더 무거운 모델)·bash

# 장기 branch:
git switch develop
git switch -c feature/oauth-integration develop

# Feature 를 develop 으로 (main 아님!):
git switch develop
git merge --no-ff feature/oauth-integration

# develop 에서 release branch:
git switch -c release/2.4.0 develop
# ... 이 branch 엔 bug fix 만, 그 다음:
git switch main
git merge --no-ff release/2.4.0
git tag -a v2.4.0 -m "Release 2.4.0"
git switch develop
git merge --no-ff release/2.4.0      # fix 를 develop 에 다시 가져옴
git branch -d release/2.4.0

Exercise

실제로 작업하는 프로젝트 하나 골라. 현재 사용 중인 workflow 를 한 단락으로 설명하고 셋 중 어느 모델에 가장 가까운지 식별. 그 모델이 만드는 마찰 포인트 둘 list (예: 장기 branch, release 중간 freeze). 마지막으로 다른 모델로 전환할지 + 전환 비용은 뭔지 적어.

GitHub Flow, Trunk-Based, GitFlow

Workflow 선택, 그 선택이 모든 걸 결정

Code

External links

Exercise

Progress

댓글 0