88 lines
2.1 KiB
Markdown
88 lines
2.1 KiB
Markdown
# 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` 로 깔끔하게 이력을 유지하는 게 좋을까요?
|