본문 바로가기
C.W.K.
Stream
Lesson 01 of 04 · published

GitHub Flow, Trunk-Based, GitFlow

~22 min · workflow, branching-strategy

Level 0추적 전 새싹
0 XP0/47 lessons0/14 achievements
0/100 XP to next level100 XP to go0% complete

Workflow 선택은 나머지 규칙을 결정해

Workflow라는 말은 부드럽지만 branch 수명, release 주기, conflict 빈도, CI 구조까지 결정해. 대표 pattern 셋은 서로 다른 팀에 맞아. 가장 나쁜 선택은 뒤섞는 거야. 절반은 GitFlow, 절반은 trunk-based처럼 행동하면 main에 양립하기 어려운 두 모양의 commit이 들어와. 하나를 고르고 문서화한 뒤 플랫폼 설정으로 강제해.

GitHub Flow가 가장 단순해. main은 언제나 배포할 수 있고, 모든 변경은 main에서 갈라진 짧은 feature branch에서 만들어 PR, review, merge 또는 rebase를 거쳐 land하고 배포해. 오래 사는 develop이나 release branch는 없어. 현대 web과 SaaS처럼 연속 배포하는 팀에 맞고 branch에서 배포까지 몇 시간 안에 끝나. 단, CI/CD가 실제로 작동해야 'main은 배포 가능하다'는 약속이 참이 돼.

Trunk-Based Development는 더 나아가 대부분의 엔지니어가 main에 직접 commit하거나 몇 시간짜리 PR만 써. feature branch는 드물고 미완성 기능은 feature flag 뒤에 숨겨 하루에도 여러 번 release해. 빠른 feedback에 최적화된 팀이 쓰며 강한 feature flag, 넓은 test, main이 깨지면 모든 일을 멈추고 몇 분 안에 고친다는 문화가 필요해.

GitFlow는 가장 무거워. main은 운영 release만 담고 develop이 통합 branch가 돼. feature는 develop에서 갈라지고 release branch에서 tagged release를 안정화하며, hotfix는 main에서 바로 갈라져 main과 develop 양쪽으로 돌아가. desktop app, semver library, 규제 software처럼 versioned product를 ship하는 팀에 맞아. 재현 가능한 release line을 얻는 대신 복잡성을 치르므로 연속 배포에는 어울리지 않아.

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

External links

Exercise

실제로 작업하는 프로젝트 하나를 골라 현재 workflow를 한 단락으로 설명하고 세 model 가운데 어디에 가장 가까운지 밝혀. 그 model이 만드는 마찰 두 가지를 적어. 오래 사는 branch나 release 중 freeze 같은 것이 예야. 마지막으로 다른 model로 바꿀지, 바꾼다면 비용은 무엇인지 적어봐.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.