# GIT branch

## 📌 장기간 개발용 브랜치 전략

### 1. 메인(main) 브랜치

* 항상 **안정된 코드**
* 실제 서비스/라이브에서 사용하는 코드
* 여기서는 직접 실험하지 않음

### 2. 기능(feature) 브랜치

* 장기간 개발할 기능을 위한 브랜치
* 예시: `feature/new-parser`, `feature/ui-redesign`

---

## 📌 워크플로우

### 1. 기능 브랜치 생성

```bash
git checkout main
git pull origin main   # 최신화
git checkout -b feature/new-parser
```

### 2. 기능 개발 (여러 번 커밋)

```bash
# 코드 수정
git add .
git commit -m "초기 버전: XML 파서 구조 추가"
```

* 계속 개발하면서 커밋 누적
* 필요하면 `git push origin feature/new-parser` 해서 원격에도 올려두기 (백업용)

### 3. 장기간 개발 중 main 따라가기 (동기화)

* main 브랜치가 바뀌면, 기능 브랜치로 가져와야 충돌 줄임

```bash
git checkout main
git pull origin main
git checkout feature/new-parser
git merge main      # main의 최신 내용 병합
```

⚡ 이 과정을 정기적으로 하면 `feature` 브랜치가 main과 멀어지지 않음

### 4. 기능 완료 → main에 병합

```bash
git checkout main
git pull origin main
git merge feature/new-parser
git push origin main
```

### 5. 필요 시 브랜치 삭제

```bash
git branch -d feature/new-parser
git push origin --delete feature/new-parser
```

---

## 📌 네이밍 규칙 (혼자 관리할 때도 편리)

* `feature/기능명` : 장기간 개발용 (예: `feature/new-ui`)
* `fix/버그명` : 버그 수정용 (예: `fix/xml-encoding`)
* `test/실험명` : 단기 테스트용 (예: `test/xpath`)

---

✅ 정리

* **main = 안정 코드**
* **feature 브랜치 = 장기간 개발용** (필요할 때 main과 동기화)
* 완료되면 main에 병합 → 안정화
* 이렇게 하면 실험/개발/운영 코드가 깔끔하게 분리됨

---

👉 기능 브랜치 개발 중에, **main 브랜치 변경분을 가져올 때** `merge` 방식이 편할까요, 아니면 `rebase` 로 깔끔하게 이력을 유지하는 게 좋을까요?