125 lines
7.8 KiB
Markdown
125 lines
7.8 KiB
Markdown
# Git 브랜치 전략 가이드
|
|
|
|
## 1. 개요
|
|
|
|
본 문서는 프로젝트의 규모와 팀 구성에 따라 유연하게 적용할 수 있는 Git 브랜치 관리 전략을 정의합니다. 일관된 브랜치 전략은 코드의 안정성을 보장하고, 협업 효율성을 높이며, 배포 프로세스를 체계적으로 관리하는 데 필수적입니다.
|
|
|
|
이 가이드에서는 혼자 개발할 때의 단순한 모델부터 팀 단위 협업 전략, 그리고 AI 에이전트를 활용한 고급 병렬 개발 워크플로우까지 다룹니다.
|
|
|
|
## 2. 브랜치 전략의 핵심: 분리
|
|
|
|
브랜치를 사용하는 핵심 이유는 **독립적인 작업 공간을 확보**하는 것입니다. 메인 코드(주로 `main` 또는 `master` 브랜치)의 안정성을 해치지 않으면서 새로운 기능을 개발하거나, 버그를 수정하고, 다양한 아이디어를 실험할 수 있습니다.
|
|
|
|
---
|
|
|
|
## 3. 프로젝트 규모별 브랜치 전략
|
|
|
|
### 3.1. 혼자 작업할 때 (Solo-developer)
|
|
|
|
혼자 개발하더라도 브랜치를 사용하는 것은 매우 유용합니다. 복잡한 전략 대신, 간단한 규칙으로도 안정적인 코드 관리가 가능합니다.
|
|
|
|
- **주요 브랜치**:
|
|
- `main` (or `master`): 항상 배포 가능한 안정적인 상태를 유지하는 브랜치.
|
|
- `feature/<기능명>`: 새로운 기능 개발, 버그 수정 등 특정 작업을 위한 임시 브랜치.
|
|
|
|
- **워크플로우**:
|
|
1. `main` 브랜치에서 새로운 작업 브랜치를 생성합니다. (`git checkout -b feature/login-page`)
|
|
2. 해당 브랜치에서 기능을 개발하고 커밋합니다.
|
|
3. 작업이 완료되면 `main` 브랜치로 돌아와 작업 브랜치를 병합(merge)합니다. (`git merge feature/login-page`)
|
|
4. 불필요해진 작업 브랜치는 삭제합니다. (`git branch -d feature/login-page`)
|
|
|
|
- **장점**:
|
|
- 실험적인 기능을 `main`과 분리하여 안전하게 개발할 수 있습니다.
|
|
- 작업 단위별로 커밋 히스토리가 관리되어 추적이 용이합니다.
|
|
- 실수로 인한 문제를 `main` 브랜치에 직접 반영하는 것을 방지합니다.
|
|
|
|
### 3.2. 두 사람 이상 팀으로 작업할 때
|
|
|
|
팀 단위 협업에서는 충돌을 방지하고 코드 품질을 유지하기 위해 더 체계적인 브랜치 전략이 필요합니다. **Git Flow**나 **GitHub Flow**가 대표적입니다.
|
|
|
|
- **주요 브랜치**:
|
|
- `main` (or `master`): 최종 배포 버전의 소스 코드를 관리하는 브랜치.
|
|
- `develop`: 다음 버전 배포를 위해 개발된 기능들이 통합되는 브랜치.
|
|
- `feature/<기능명>`: `develop` 브랜치에서 파생되어 개별 기능 개발을 진행.
|
|
- `release/<버전>`: 배포를 준비하기 위해 `develop` 브랜치에서 파생. QA 및 버그 수정을 진행.
|
|
- `hotfix/<수정내용>`: `main` 브랜치에 발생한 긴급 버그를 수정하기 위해 파생.
|
|
|
|
- **워크플로우**:
|
|
1. 모든 기능 개발은 `develop` 브랜치에서 시작합니다.
|
|
2. 개발자는 `feature` 브랜치를 생성하여 독립적으로 작업합니다.
|
|
3. 개발 완료 후, `develop` 브랜치로 **Pull Request(PR)** 또는 **Merge Request(MR)**를 보냅니다.
|
|
4. **코드 리뷰**와 **자동화된 테스트(CI)**를 통과한 코드만 `develop` 브랜치에 병합됩니다.
|
|
5. 배포 시점이 되면 `develop` 브랜치의 코드를 `release` 브랜치로 옮겨 QA를 진행하고, 최종적으로 `main`과 `develop`에 병합합니다.
|
|
6. 배포된 `main` 브랜치에서 긴급한 버그 발생 시, `hotfix` 브랜치에서 수정 후 `main`과 `develop`에 즉시 반영합니다.
|
|
|
|
- **핵심 차이점**:
|
|
| 구분 | 혼자 작업할 때 | 팀 작업할 때 |
|
|
| :--- | :--- | :--- |
|
|
| **규칙** | 비교적 자유로움 | 명확한 네이밍, 병합 규칙 필수 |
|
|
| **병합** | 본인 판단 하에 직접 병합 | Pull Request와 코드 리뷰를 통한 병합 |
|
|
| **충돌** | 거의 발생하지 않음 | 빈번하며, 적극적인 소통과 관리 필요 |
|
|
|
|
---
|
|
|
|
## 4. AI 기반 병렬 개발 워크플로우 (고급)
|
|
|
|
LLM(거대 언어 모델) AI 에이전트의 비결정적 특성을 활용하여 여러 구현 방안을 동시에 탐색하고 최상의 결과물을 선택하는 고급 워크플로우입니다. **Git Worktrees**를 사용해 물리적으로 분리된 작업 디렉토리에서 여러 AI 세션을 동시에 실행하는 것이 핵심입니다.
|
|
|
|
### 4.1. Git Worktrees란?
|
|
|
|
하나의 Git 저장소에 대해 여러 개의 워킹 디렉토리(working tree)를 생성하는 기능입니다. 동일한 `.git` 디렉토리를 공유하면서 각 디렉토리에서는 다른 브랜치를 체크아웃하여 작업할 수 있어, 브랜치 전환 없이 여러 작업을 병렬로 수행할 수 있습니다.
|
|
|
|
### 4.2. 워크플로우 제안
|
|
|
|
1. **작업별 워크트리 생성**: 각 기능이나 실험마다 별도의 워크트리를 생성합니다.
|
|
```bash
|
|
# 'feature/A' 브랜치를 만들고 ../gui-gitea-operation-feature-A 디렉토리에 워크트리 생성
|
|
git worktree add ../gui-gitea-operation-feature-A -b feature/A
|
|
|
|
# 'feature/B' 브랜치를 만들고 ../gui-gitea-operation-feature-B 디렉토리에 워크트리 생성
|
|
git worktree add ../gui-gitea-operation-feature-B -b feature/B
|
|
```
|
|
|
|
2. **독립적인 AI 세션 실행**: 각 워크트리 디렉토리로 이동하여 독립적인 AI 코딩 세션을 실행합니다.
|
|
```bash
|
|
# A 작업용 터미널
|
|
cd ../gui-gitea-operation-feature-A && code . # 또는 claude, cursor 등 AI 에이전트 실행
|
|
|
|
# B 작업용 터미널
|
|
cd ../gui-gitea-operation-feature-B && code . # 또는 claude, cursor 등 AI 에이전트 실행
|
|
```
|
|
이제 각 AI 에이전트는 서로 영향을 주지 않고 지정된 브랜치에서 코드를 생성하고 수정합니다.
|
|
|
|
3. **결과 비교 및 선택**:
|
|
- 각 워크트리에서 작업이 완료되면 커밋 후 원격 저장소에 푸시합니다.
|
|
- 각 브랜치에 대해 Pull Request(PR)를 생성합니다.
|
|
- PR에서 코드 리뷰, CI 테스트, 성능 비교 등을 통해 가장 우수한 결과물을 선택합니다.
|
|
- 선택된 PR을 메인 개발 브랜치(`develop` 또는 `main`)에 병합합니다.
|
|
|
|
4. **정리**: 작업이 완료된 워크트리는 리소스를 절약하기 위해 제거합니다.
|
|
```bash
|
|
git worktree remove ../gui-gitea-operation-feature-A
|
|
git worktree remove ../gui-gitea-operation-feature-B
|
|
```
|
|
|
|
### 4.3. 병렬 워크플로우 최적화 팁
|
|
|
|
| 항목 | 권장 사항 |
|
|
| :--- | :--- |
|
|
| **네이밍** | `feature/기능명`, `experiment/실험명` 등 목적을 명확히 하는 네이밍 규칙 사용 |
|
|
| **초기화** | 각 워크트리 진입 시 의존성 설치 등 환경 초기화 스크립트 실행 |
|
|
| **리소스 관리** | `git worktree list`로 현재 워크트리를 확인하고 불필요한 것은 즉시 제거 |
|
|
| **비교/선택** | PR의 CI 결과, 코드 커버리지, 성능 지표 등 객관적 데이터로 최종 결과물 선택 |
|
|
| **비용 관리** | AI 에이전트 사용 비용을 고려하여, 동시에 실행하는 워크트리 수를 2~3개로 제한 |
|
|
|
|
---
|
|
|
|
## 5. 결론
|
|
|
|
브랜치 전략은 "정답"이 있는 것이 아니라, 프로젝트의 상황에 맞춰 선택하는 것입니다.
|
|
|
|
- **혼자서는** `main` + `feature`의 단순한 모델로도 충분합니다.
|
|
- **팀에서는** `Git Flow`와 같이 역할이 명확히 구분된 체계적인 전략과 PR 기반의 협업 문화가 필수적입니다.
|
|
- **복잡한 문제 해결이나 R&D**에서는 `Git Worktrees`를 활용한 병렬 AI 개발이 생산성과 코드 품질을 극대화하는 강력한 무기가 될 수 있습니다.
|
|
|
|
상황에 맞는 전략을 선택하고 팀원 모두가 일관되게 규칙을 따르는 것이 성공적인 프로젝트 관리의 핵심입니다. |