개발
Git 워크플로우 심화
Git은 단순 버전 관리 도구를 넘어 팀 협업의 설계 언어다. 브랜치 전략, 커밋 컨벤션, 자동화 훅까지 체계화하면 코드 리뷰 품질과 배포 안정성이 동시에 높아진다.
브랜치 전략 비교
| 전략 | 특징 | 팀 규모 | 릴리즈 주기 |
|---|---|---|---|
| Git Flow | 엄격한 분기 구조 | 대형 | 주기적(월·분기) |
| GitHub Flow | 단순: main + feature | 소~중형 | 지속적 |
| GitLab Flow | 환경별 브랜치 추가 | 중~대형 | 지속적+스테이징 |
| Trunk-Based | 단일 main, 짧은 수명 브랜치 | 고성숙 팀 | 하루 여러 번 |
1인 또는 소규모 SaaS 팀에는 GitHub Flow가 가장 실용적이다. feature → PR → main 단일 흐름이 오버헤드 없이 CI/CD와 자연스럽게 연결된다.
커밋 컨벤션
Conventional Commits
커밋 메시지 형식:
<type>(<scope>): <subject>
<body>
<footer>
- type: feat | fix | docs | style | refactor | test | chore
- scope: 영향받는 모듈(선택)
- subject: 현재 시제, 대문자 시작 금지, 마침표 금지
예: feat(auth): add Google OAuth2 login
이 컨벤션을 따르면 semantic-release로 버전 자동 발행이 가능하다.
리베이스 vs 머지
언제 리베이스를 쓰나
로컬 feature 브랜치를 main의 최신 상태로 업데이트할 때 git rebase main을 쓰면 히스토리가 선형으로 유지된다. git merge main은 머지 커밋이 생겨 히스토리가 복잡해진다[^1].
절대 공유 브랜치에는 리베이스하지 않는다. 다른 팀원이 동일 커밋을 참조하고 있으면 히스토리 불일치로 충돌이 발생한다.
인터랙티브 리베이스
git rebase -i HEAD~5
마지막 5개 커밋을 squash, reword, drop할 수 있다. PR 전에 "WIP" 커밋들을 깔끔하게 정리하는 데 사용한다.
Git Hooks 자동화
로컬 훅 (pre-commit)
커밋 직전에 린트·포맷·테스트를 강제한다.
# .husky/pre-commit
npm run lint && npm run typecheck
Husky + lint-staged 조합이 Node.js 프로젝트 표준이다.
서버사이드 훅 (pre-receive)
CI 완료, 코드 리뷰 승인, 브랜치 보호 규칙을 서버에서 강제한다. GitHub Actions의 required status checks가 이 역할을 담당한다.
대형 파일 관리
바이너리, 모델 가중치, 영상 파일은 Git LFS(Large File Storage)로 관리한다. LFS는 포인터 파일만 저장소에 넣고 실제 파일은 별도 스토리지에 보관한다. 저장소 크기를 10배 이상 줄이는 효과가 있다.
비상 명령어
- 잘못된 커밋 취소(공유 전): git reset --soft HEAD~1 (커밋만 취소, 변경사항 유지)
- 특정 파일만 되돌리기: git checkout HEAD -- path/to/file
- 삭제된 브랜치 복구: git reflog로 커밋 해시 찾아 git checkout -b 브랜치명 해시
- 스태시 목록: git stash list, git stash pop stash@{0}
1인 SaaS 운영에서 Git 전략을 사업화 흐름과 연결하는 방법은 1인 개발자 SaaS 사업화 완전가이드를 참고하라.
[^1]: Pro Git Book, Scott Chacon. "리베이스는 히스토리를 다시 쓴다. 공유 브랜치에서는 팀원의 작업 기반을 파괴할 수 있다."