Git이 협업의 핵심인 이유
Git은 단순한 버전 관리 도구가 아닙니다. 팀이 어떻게 Git을 사용하느냐가 개발 속도, 코드 품질, 배포 안정성을 결정합니다. 전략 없이 Git을 쓰면 충돌과 혼란이 반복되고, 잘 설계된 브랜치 전략 하나로 수십 명이 동시에 작업해도 코드베이스가 깔끔하게 유지됩니다.
이 가이드에서는 대표적인 브랜치 전략 세 가지와 협업에서 자주 쓰는 실전 명령어, 그리고 merge vs rebase 선택 기준까지 다룹니다.
1부: 브랜치 전략 3가지
① Git Flow
Vincent Driessen이 2010년 제안한 전략으로, 정해진 릴리즈 주기가 있는 프로젝트에 적합합니다.
- main: 항상 배포 가능한 상태. 태그(버전)를 붙여 릴리즈 관리
- develop: 다음 릴리즈를 위한 통합 브랜치. 모든 기능이 여기 합쳐짐
- feature/xxx: 기능 개발 브랜치. develop에서 분기 → develop으로 머지
- release/x.x: 릴리즈 준비 브랜치. QA, 버그 수정 후 main + develop 양쪽에 머지
- hotfix/xxx: 긴급 버그 수정. main에서 분기 → main + develop 양쪽에 머지
# Git Flow 초기화 (git-flow 확장 설치 후)
git flow init
# 기능 브랜치 시작
git flow feature start user-authentication
# 기능 완료 (develop에 자동 머지 + 브랜치 삭제)
git flow feature finish user-authentication
# 릴리즈 시작
git flow release start 1.2.0
# 릴리즈 완료 (main + develop 머지 + 태그 생성)
git flow release finish 1.2.0장점: 명확한 역할 분리, 병렬 개발 용이
단점: 복잡하고 머지가 잦아짐. CI/CD 중심 팀에는 과할 수 있음
② GitHub Flow
GitHub이 사용하는 단순한 전략. main 하나를 항상 배포 가능하게 유지하고, 기능마다 브랜치를 만들어 PR로 머지합니다.
# main에서 기능 브랜치 생성
git checkout -b feature/dark-mode
# 작업 후 push
git push origin feature/dark-mode
# GitHub에서 PR 생성 → 코드 리뷰 → 승인 → main에 머지
# 머지 즉시 배포장점: 단순하고 빠름. CI/CD와 찰떡궁합
단점: 릴리즈 버전 관리가 필요한 프로젝트에는 부적합
③ 트렁크 기반 개발 (Trunk-Based Development)
Google, Facebook 등 대형 기술 기업이 사용하는 전략. 모든 개발자가 매일 main(trunk)에 직접 커밋하거나, 수명이 매우 짧은 브랜치(1~2일)만 사용합니다.
- 피처 플래그(Feature Flag)로 미완성 기능을 main에 포함시키되 비활성화
- 지속적 통합(CI)이 강력하게 필요함
- 소규모 팀이나 DevOps 성숙도가 높은 팀에 적합
# 브랜치 없이 main에 직접 커밋
git checkout main
git pull
# ... 작업 ...
git add .
git commit -m "feat: add dark mode (behind feature flag)"
git push origin main장점: 머지 지옥 없음. 배포 주기 극대화
단점: 강력한 테스트 자동화와 규율이 없으면 main이 불안정해짐
2부: Merge vs Rebase — 언제 뭘 써야 하나
Merge
두 브랜치의 히스토리를 합쳐 머지 커밋을 생성합니다. 히스토리가 그대로 보존됩니다.
# feature 브랜치에서 main의 변경사항 가져오기 (merge)
git checkout feature/dark-mode
git merge main
# 결과: 머지 커밋이 생기고 두 히스토리가 합쳐짐
# * Merge branch 'main' into feature/dark-mode
# |\
# | * main의 최신 커밋
# * | feature 커밋
# |/언제 쓰나: 공개 브랜치(main, develop), PR 완료 시, 히스토리 보존이 중요할 때
Rebase
현재 브랜치의 커밋들을 기준 브랜치 위에 다시 쌓습니다. 선형(linear)의 깔끔한 히스토리를 만들 수 있습니다.
# feature 브랜치에서 main의 변경사항 가져오기 (rebase)
git checkout feature/dark-mode
git rebase main
# 결과: feature 커밋들이 main의 최신 커밋 위에 재작성됨
# * feature 커밋 (새 해시로 재작성됨)
# * main의 최신 커밋
# 충돌 발생 시
git rebase --continue # 충돌 해결 후
git rebase --abort # 되돌리기언제 쓰나: 로컬 개발 브랜치 정리, PR 전 커밋 정리, 히스토리를 깔끔하게 유지하고 싶을 때
황금 규칙: 공개된 브랜치는 절대 rebase하지 않는다
이미 push된 브랜치를 rebase하면 커밋 해시가 변경되어 팀원들의 히스토리와 충돌합니다. 혼자만 쓰는 로컬 브랜치에서만 rebase하세요.
3부: 충돌 해결 실전
충돌이 발생하면
# 충돌 파일 확인
git status
# both modified: src/components/Header.tsx
# 파일 열어보면 충돌 마커가 표시됨
# <<<<<<< HEAD (현재 브랜치)
# const title = "새로운 제목";
# =======
# const title = "기존 제목";
# >>>>>>> main (머지되는 브랜치)
# 수동으로 원하는 코드로 편집 후 마커 제거
# 그 다음 스테이지에 추가
git add src/components/Header.tsx
git commit # 머지인 경우
git rebase --continue # rebase인 경우시각적 도구 활용
- VS Code: 충돌 파일에서 "Accept Current", "Accept Incoming", "Accept Both" 버튼 제공
- IntelliJ / WebStorm: 3-way merge 뷰 지원
- git mergetool: vimdiff, opendiff 등 외부 도구 연동
# 머지 전 공통 조상 기준으로 3-way diff 보기
git diff --base conflicted-file.ts
# 특정 브랜치 버전으로 파일 통째로 교체
git checkout --ours src/config.ts # 내 버전 유지
git checkout --theirs src/config.ts # 상대 버전 수용4부: 꼭 알아야 할 실전 명령어
커밋 수정
# 마지막 커밋 메시지 수정
git commit --amend -m "fix: 올바른 커밋 메시지"
# 마지막 커밋에 파일 추가 (push 전에만)
git add forgotten-file.ts
git commit --amend --no-edit
# 최근 3개 커밋 대화형으로 정리 (squash, reorder, etc.)
git rebase -i HEAD~3stash — 작업 임시 보관
# 현재 변경사항 임시 저장
git stash
# 다른 브랜치 작업 후 복원
git stash pop
# 여러 stash 관리
git stash list
git stash apply stash@{2}
git stash drop stash@{0}
# 메시지와 함께 저장
git stash push -m "작업 중인 로그인 폼"cherry-pick — 특정 커밋만 가져오기
# 다른 브랜치의 특정 커밋만 현재 브랜치에 적용
git cherry-pick a1b2c3d
# 여러 커밋 범위 cherry-pick
git cherry-pick a1b2c3d..f6g7h8i
# 커밋 없이 변경사항만 적용
git cherry-pick -n a1b2c3dbisect — 버그 도입 커밋 이진 탐색
# 버그가 언제 들어왔는지 모를 때
git bisect start
git bisect bad # 현재는 버그 있음
git bisect good v1.0.0 # 1.0.0은 정상이었음
# Git이 중간 커밋 checkout → 테스트 후
git bisect good # 이 커밋은 정상
git bisect bad # 이 커밋에서 버그 있음
# 반복하면 Git이 버그 커밋 자동 특정
# 완료 후
git bisect resetlog 활용
# 그래프로 히스토리 보기
git log --oneline --graph --all --decorate
# 특정 파일의 변경 이력
git log -p src/auth/login.ts
# 특정 문자열이 추가/제거된 커밋 찾기
git log -S "getUserById" --source --all
# 기간 필터
git log --since="2026-01-01" --until="2026-03-11" --author="홍길동"
# 커밋 통계
git shortlog -sn # 저자별 커밋 수5부: 좋은 커밋 메시지 작성법
좋은 커밋 메시지는 코드를 읽지 않아도 무슨 일이 있었는지 알 수 있게 해줍니다. Conventional Commits 규칙을 따르면 자동화 도구(CHANGELOG 생성, 버전 범핑)와도 연동됩니다.
# 형식: <type>(<scope>): <subject>
feat(auth): 소셜 로그인 카카오 연동 추가
fix(cart): 수량 0 입력 시 음수로 변경되는 버그 수정
docs(readme): 환경변수 설정 방법 업데이트
refactor(api): 중복 HTTP 클라이언트 코드 통합
test(auth): 토큰 만료 엣지 케이스 테스트 추가
chore(deps): react 18.3.0으로 업그레이드
# type 종류
# feat → 새로운 기능
# fix → 버그 수정
# docs → 문서만 변경
# style → 코드 스타일 (세미콜론, 공백 등)
# refactor → 기능 변경 없는 리팩토링
# test → 테스트 추가/수정
# chore → 빌드, 의존성 등 기타6부: .gitignore 제대로 설정하기
# Node.js 프로젝트 기본 .gitignore
node_modules/
dist/
build/
.env
.env.local
.env.*.local
# OS 파일
.DS_Store
Thumbs.db
# IDE
.vscode/settings.json
.idea/
*.swp
# 로그
*.log
npm-debug.log*
# 이미 추적되던 파일을 gitignore에 추가 후 무시하려면
git rm --cached .env
git commit -m "chore: remove .env from tracking"7부: PR 리뷰 잘 받는 법
- 작게 쪼개기: 하나의 PR은 하나의 목적만. 400줄 이하 권장
- 설명 충실하게: 왜 이 변경이 필요한지, 어떻게 테스트했는지 작성
- 스스로 먼저 리뷰: PR 열기 전 diff를 직접 확인
- Draft PR 활용: 작업 중 조기 피드백을 받고 싶을 때
- 변경사항 요약: 리뷰어가 어디서 봐야 할지 알려주기
## 변경 사항
- 카카오 소셜 로그인 API 연동
- 액세스 토큰/리프레시 토큰 자동 갱신 로직 추가
## 테스트 방법
1. 로컬 환경변수 KAKAO_CLIENT_ID 설정
2. /login 페이지에서 카카오 버튼 클릭
3. 인증 후 /dashboard로 리다이렉트 확인
## 스크린샷
(이미지 첨부)
## 관련 이슈
closes #42팀에 맞는 전략 선택하기
- 1~3인 소규모 팀 또는 스타트업: GitHub Flow 추천. 단순하고 빠름
- 명확한 릴리즈 주기가 있는 팀 (앱 스토어, 패키지): Git Flow 추천
- CI/CD 성숙도가 높고 하루에 여러 번 배포하는 팀: 트렁크 기반 개발 추천
전략보다 더 중요한 건 팀 전체가 같은 규칙을 따르는 것입니다. 문서화하고, 온보딩 때 전달하고, 주기적으로 리뷰하세요.
마무리
Git은 배울수록 강력해지는 도구입니다. 브랜치 전략과 기본 명령어를 익혔다면, 다음은 Git Hooks로 커밋 전 린트 자동화, GitHub Actions로 CI/CD 파이프라인 구축을 시도해보세요. 코드가 아니라 협업의 방식이 달라집니다.
코드 비교가 필요할 때는 Diff 체커 도구를 활용해 변경사항을 시각적으로 확인해보세요.