Git 브랜치 전략과 협업 워크플로우: 팀 개발의 핵심

Git이 필수인 이유

Git은 현대 소프트웨어 개발의 필수 도구입니다. 코드 버전 관리, 협업, 백업, 배포 자동화의 기반이 됩니다. 하지만 Git을 "잘" 사용하는 것은 별개의 문제입니다.

Git Branches

Git 워크플로우 종류

1. Git Flow

가장 전통적이고 체계적인 워크플로우입니다.

브랜치 구조

main: 프로덕션 코드
develop: 개발 통합 브랜치
feature/*: 기능 개발
release/*: 릴리스 준비
hotfix/*: 긴급 수정

장점

명확한 역할 분리
릴리스 관리 용이
대규모 팀에 적합

단점

복잡함
브랜치가 너무 많아질 수 있음
CI/CD와 잘 안 맞을 수 있음

2. GitHub Flow

단순하고 CI/CD 친화적인 워크플로우입니다.

브랜치 구조

main: 항상 배포 가능
feature/*: 기능 개발

프로세스

main에서 브랜치 생성
작업 후 커밋
Pull Request 생성
코드 리뷰
main에 머지
자동 배포

장점

단순함
CI/CD와 잘 맞음
빠른 릴리스

단점

릴리스 버전 관리 어려움
대규모 프로젝트에서 복잡해질 수 있음

3. Trunk Based Development

main 브랜치에 직접, 자주 커밋하는 방식입니다.

특징

짧은 수명의 브랜치 (1-2일)
피처 플래그 사용
지속적 통합 강조

장점

머지 충돌 최소화
빠른 피드백
간단한 브랜치 구조

단점

피처 플래그 관리 필요
높은 테스트 커버리지 요구

Team Coding

커밋 메시지 작성법

Conventional Commits

표준화된 커밋 메시지 형식입니다.

형식 type(scope): description

타입

feat: 새 기능
fix: 버그 수정
docs: 문서 변경
style: 포맷팅 (코드 변경 없음)
refactor: 리팩토링
test: 테스트 추가
chore: 빌드, 설정 변경

예시

feat(auth): 소셜 로그인 추가
fix(cart): 수량 계산 오류 수정
docs(readme): 설치 가이드 업데이트

좋은 커밋 메시지

명령형 현재 시제 사용 ("Add" not "Added")
첫 줄 50자 이내
무엇을, 왜 변경했는지 설명

DON'T

"수정", "업데이트" 같은 모호한 메시지
너무 많은 변경을 하나의 커밋에
커밋 메시지 없이 커밋

Code Review

Pull Request 베스트 프랙티스

PR 생성

작게 유지

200-400줄 이내
하나의 목적
리뷰어 피로 방지

명확한 설명

변경 사항 요약
테스트 방법
스크린샷 (UI 변경 시)

코드 리뷰

리뷰어로서

건설적인 피드백
질문 형태로 제안
칭찬도 함께

작성자로서

피드백에 열린 자세
명확한 답변
빠른 대응

유용한 Git 명령어

실수 복구

마지막 커밋 수정 git commit --amend

스테이징 취소 git reset HEAD <file>

커밋 취소 (이력 유지) git revert <commit>

브랜치 관리

원격 브랜치 정리 git fetch --prune

머지된 브랜치 삭제 git branch --merged | xargs git branch -d

Collaboration

.gitignore 관리

프로젝트에 불필요한 파일을 추적하지 않도록 합니다.

포함할 것

node_modules/
.env
build/
*.log
IDE 설정 (.vscode/, .idea/)

gitignore.io 프로젝트 타입에 맞는 .gitignore 생성 도구

Git Hooks

커밋, 푸시 전후에 자동으로 실행되는 스크립트입니다.

활용 예시

pre-commit: 린트, 포맷팅
commit-msg: 커밋 메시지 검증
pre-push: 테스트 실행

도구

Husky
lint-staged

마무리

Git을 잘 사용하면 협업 효율이 크게 향상됩니다. SpacePlanning은 팀에 맞는 Git 워크플로우 설계를 도와드립니다.