# [[React Project Git Governance]]

## 📌 Brief Summary
React 프로젝트 Git 거버넌스는 협업 환경에서 코드 품질을 유지하고 충돌을 방지하기 위해 정의된 브랜치 생성, 커밋 메시지 작성, 풀 리퀘스트(PR) 관리 등의 규칙과 워크플로우를 의미합니다. 소규모 및 대규모 팀에서 메인 브랜치의 안정성을 배포 가능한 상태로 지속 유지하며, 기능 브랜치(Feature Branch) 운용, 티켓 ID 연동, Conventional Commits, 그리고 자동화된 시각적 회귀 테스트(Visual Regression Testing) 등을 통합하여 빠른 피드백 루프와 명확한 추적성을 확보하는 데 중점을 둡니다.

## 📖 Core Content
*   **브랜치 전략 (Branching Strategies):** 소규모 팀(2~5명)의 경우 복잡한 Git-Flow 워크플로우보다는 '보호된 메인 브랜치를 갖춘 단순 기능 브랜치 워크플로우(Feature-branch workflow)' 또는 단기 기능 브랜치를 활용하는 '트렁크 기반(Trunk-based) 워크플로우'가 권장됩니다. `main` 브랜치는 항상 안정적이고 즉시 배포 가능한 상태여야 하며, 개발자는 절대 `main` 브랜치에 직접 커밋해서는 안 됩니다.
*   **브랜치 명명 규칙 (Branch Naming Conventions):** 설명이 명확한 짧은 이름을 사용하되, `feature/`, `bugfix/`, `chore/` 등의 유형 접두사를 사용합니다. 이슈 추적성(Traceability)을 위해 JIRA 등의 티켓 ID를 포함하는 것이 좋습니다(예: `feature/PROJ-123-user-auth`). 단어 구분에는 언더스코어(_) 대신 하이픈(-)을 사용하고, 소문자로 통일합니다.
*   **커밋 규칙 (Commit Rules):** 하나의 커밋은 하나의 논리적 변경사항만 포함하는 원자적 커밋(Atomic Commit)이어야 합니다. 커밋 메시지는 'Conventional Commits' 사양(`feat:`, `fix:`, `refactor:` 등)을 따라 작성하여 히스토리를 쉽게 스캔하고 릴리스 노트를 자동화할 수 있게 합니다. 변경된 내용(What)과 그 이유(Why)를 명확히 작성해야 합니다.
*   **PR(Pull Request) 및 병합(Merging) 규칙:** 코드를 병합하기 전 반드시 PR을 생성해야 하며, 최소 1명 이상의 동료 코드 리뷰 승인과 CI 테스트 통과가 필수입니다. PR은 빠르고 철저한 리뷰를 위해 단일 작업에 집중된 작은 크기로 유지해야 합니다. 병합 시에는 커밋 히스토리를 깔끔하게 유지하기 위해 스쿼시 병합(Squash Merge)을 주로 사용하며, 병합 후에는 기능 브랜치를 자동 삭제하여 리포지토리를 정리합니다.
*   **시각적 리뷰 및 자동화 (Visual Reviews):** 프론트엔드/React의 특성에 맞춰 Storybook과 Chromatic 같은 도구를 사용하여 PR 단계에서 시각적 회귀 테스트(Visual Regression Testing)를 수행합니다. 이를 통해 의도치 않은 UI 레이아웃, 여백, 색상 변경 등의 시각적 결함이 프로덕션에 병합되는 것을 선제적으로 차단합니다.

## ⚖️ Trade-offs & Caveats
*   **엄격한 규칙 vs 개발 오버헤드:** PR 생성, 티켓 ID 필수 포함, 최소 1인 리뷰 요구, CI/CD 빌드 및 테스트 통과 등의 엄격한 규칙은 코드 품질과 안정성을 크게 높이지만, 아주 작고 사소한 수정조차 동일한 프로세스를 거쳐야 하므로 개발 및 배포 속도에 오버헤드를 발생시킬 수 있습니다.
*   **스쿼시 병합(Squash Merge)의 단점:** 스쿼시 병합은 메인 브랜치의 히스토리를 한 줄로 깔끔하게 유지해주지만, 개발자가 개별 기능 브랜치 내에서 작업하며 남겼던 세세한 커밋 단위의 논리적 흐름이나 히스토리는 메인 브랜치에서 추적하기 어려워집니다.
*   **장기 브랜치(Long-lived Branches)의 위험:** 권장되는 '단기 기능 브랜치' 원칙을 어기고 기능 브랜치를 너무 오래 유지할 경우, 메인 브랜치와의 동기화가 크게 틀어져 추후 거대한 병합 충돌(Merge Conflict)이 발생하며 이를 해결하는 데 막대한 시간이 소모됩니다.
*   **Trunk-based 개발 전환 시의 요구사항:** 빠른 통합을 위해 Trunk-based 개발로 전환하려면 팀원 간의 긴밀한 조율과 높은 숙련도가 필요합니다. 또한 완료되지 않은 기능이 사용자에게 노출되지 않도록 기능 플래그(Feature Flags)를 도입하고 강력한 테스트 환경을 갖추어야 하는 추가적인 관리 부담이 따릅니다.

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처/기반 기술]
- [[Feature-branch workflow]]
  - 연결 이유: 소규모 React 팀에서 코드 충돌을 줄이고 메인 브랜치 안정성을 유지하기 위한 가장 권장되는 기본 Git 브랜치 전략입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 기능 개발을 격리하고 안전하게 통합(Merge)하는 전체 수명 주기 원리.
- [[Conventional Commits]]
  - 연결 이유: 커밋 메시지 형식을 표준화하여 자동화된 릴리스 노트 작성과 명확한 코드 히스토리 관리를 가능하게 하는 핵심 거버넌스 규칙입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat`, `fix`, `chore` 등 커밋 타입의 정확한 의미와 기계가 읽을 수 있는(machine-readable) 히스토리 관리 방법.

#### [관계 유형 B: 구현/활용 도구 및 프로세스]
- [[Pull Request (PR) Etiquette]]
  - 연결 이유: 코드가 메인 브랜치에 병합되기 전 코드 품질을 검증하는 최종 관문이자, 팀원 간의 비동기적 소통과 코드 리뷰가 이루어지는 프로세스입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: PR 크기를 작게 유지하여 리뷰 속도와 정확성을 높이는 협업 최적화 방법.
- [[Visual Regression Testing]]
  - 연결 이유: React UI 컴포넌트의 시각적 변경사항(레이아웃, 색상 등)을 PR 단계에서 자동으로 감지하고 리뷰하여 UI 결함을 방지하는 프론트엔드 특화 테스트입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Storybook과 Chromatic을 이용한 자동화된 UI 리뷰 워크플로우 및 시각적 차이 비교 원리.
- [[Squash Merge]]
  - 연결 이유: 병합 시 기능 브랜치의 여러 커밋을 단일 커밋으로 압축하여 메인 브랜치 히스토리를 정리하는 권장 병합 전략입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 병합 전략의 차이점과 버전 기록 가독성 향상.

### Deeper Research Questions

- Git-Flow, GitHub Flow, Trunk-Based Development 각각의 워크플로우는 React 프로젝트의 규모, 배포 주기, 팀 성숙도에 따라 어떻게 다르게 적용되어야 하는가?
- 단기 기능 브랜치(Short-lived feature branches)를 유지하기 위해 프론트엔드 개발자가 React 컴포넌트 및 기능 단위를 작게 분할(Task breakdown)하는 가장 효과적인 기준은 무엇인가?
- Conventional Commits 사양을 프론트엔드 CI/CD 파이프라인(예: 릴리스 버전 자동 펌핑, 체인지로그 자동 생성)과 연동할 때 발생하는 기술적 이점과 구성 상의 제약 사항은 무엇인가?
- React UI 컴포넌트에 대한 PR 리뷰 시, 전통적인 코드 리뷰(Code Review)와 Chromatic 등을 통한 시각적 리뷰(Visual Review)는 프로세스 상에서 어떻게 결합하여 시너지를 내는가?
- 지속적인 통합 및 배포(CI/CD)를 위해 Trunk-based 개발을 도입할 때, React 아키텍처 내에서 기능 플래그(Feature Flags)를 어떻게 설계하고 적용해야 하는가?

### Practical Application Contexts

- **Implementation:** React 프로젝트 초기 세팅 시, Husky 등을 사용하여 Git 프리커밋 훅(pre-commit hooks)을 설정함으로써 Conventional Commits 형식과 브랜치 명명 규칙을 팀 전체에 강제할 수 있습니다.
- **System Design:** 지라(Jira)와 같은 티켓 발행 시스템과 GitHub/GitLab을 연동하여, 생성된 모든 PR과 커밋 내역이 특정 비즈니스 요구사항(티켓 ID)과 1:1로 매핑 및 추적 가능하도록 시스템을 구축합니다.
- **Operation / Maintenance:** 저장소의 `main` 브랜치에 브랜치 보호 규칙(Branch Protection Rule)을 적용하여, 직배포를 원천 차단하고 반드시 1인 이상의 코드 리뷰 승인과 CI 빌드/테스트(예: ESLint, Storybook 테스트) 통과를 요구하도록 운영합니다.
- **Learning Path:** 개인 프로젝트에서부터 '새로운 기능 브랜치 생성 -> 의미 있는 원자적 커밋 작성 -> PR 생성 -> 코드 리뷰 시뮬레이션 -> 스쿼시 병합'의 전체 사이클을 체화하고, 점차 시각적 테스트 도구를 PR 리뷰 파이프라인에 통합하는 방법을 학습합니다.
- **My Project Relevance:** 현재 진행 중인 소규모 React 프로젝트에 복잡한 Git-Flow 대신 제안된 '보호된 메인 브랜치를 지닌 기능 브랜치 워크플로우'를 프로젝트 규칙으로 즉각 도입하여 브랜치 관리 비용과 병합 충돌을 최소화할 수 있습니다.

### Adjacent Topics

- [[CI/CD Pipelines in Frontend]]
  - 확장 방향: Git 거버넌스를 통해 엄격히 관리되어 병합된 코드가 이후 어떻게 자동으로 빌드, 테스트, 배포되는지 프론트엔드 파이프라인 전체의 구축 방법론을 탐구합니다.
- [[React Component Testing Strategies]]
  - 확장 방향: PR을 병합하기 전 CI에서 필수적으로 통과해야 하는 테스트(Unit, Integration, E2E)의 종류와 React 생태계에서 이를 효과적으로 구현하는 전략을 조사합니다.

---
*Last updated: 2026-04-30*