Git Branching Strategies and Workflows (Git 브랜칭 전략 및 워크플로우)

📌 한 줄 통찰 (The Karpathy Summary)

"코드 변경의 격리와 통합을 체계적으로 관리하여 메인 브랜치의 안정성을 수호하고, 팀의 규모와 릴리스 주기에 최적화된 협업의 고속도로를 설계하라" — 소프트웨어 형상 관리의 효율성을 결정짓는 팀 표준 워크플로우.

추출된 패턴: "Stability-driven Isolation and Continuous Integration" — 새로운 기능이나 버그 수정 작업을 독립된 브랜치에서 수행하고, PR 검증을 거쳐 안정된 코드만 메인 트렁크에 합류시키는 패턴.
팀 규모별 최적 전략:
- Feature Branch Workflow: 소규모 팀(2-5인)에 적장. 메인 브랜치에서 짧은 수명의 기능 브랜치를 분기하여 작업 후 병합.
- Trunk-Based Development: 고도로 숙련된 팀 및 강력한 CI/CD 환경에 적합. 메인 브랜치에 작고 잦은 커밋을 직접 또는 짧은 PR로 병합.
- Git Flow: 정기적 릴리스가 필요한 대규모 엔터프라이즈 프로젝트에 적합. develop, release, hotfix 등 엄격한 브랜치 계층 구조 사용.
핵심 거버넌스:
- Naming Convention: feature/, bugfix/, hotfix/ 등 접두사 활용. 티켓 ID 포함 권장.
- Commit Discipline: Conventional Commits 준수. 의미 있는 최소 단위의 커밋.
- Merge Strategy: 깔끔한 히스토리를 위한 Squash Merge 및 병합 후 브랜치 즉시 삭제.
의의: 코드 충돌을 최소화하고, 배포 리스크를 분산시키며, 협업 과정에서의 혼선을 제거하여 개발 생산성을 극대화함.

과거 데이터와의 충돌: 과거에는 무거운 Git Flow를 모든 프로젝트에 적용하려 했으나, 현대 정책은 팀 규모와 속도에 맞춰 더 가벼운 'GitHub Flow'나 'Trunk-Based Development' 정책으로 유연하게 전환하는 추세임.
정책 변화: Antigravity 프로젝트는 모든 저장소에 대해 'Feature Branch' 방식을 기본 정책으로 하며, 메인 브랜치로의 직접 커밋을 기술적으로 차단(Protected Branch)하고 반드시 PR 리뷰를 거치도록 함.