diw/회차별채점자료/2508/채점결과/git_branch_manage.md

GIT branch

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

1. 메인(main) 브랜치

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

2. 기능(feature) 브랜치

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

---

📌 워크플로우

1. 기능 브랜치 생성

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

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

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

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

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

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

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

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

4. 기능 완료 → main에 병합

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

5. 필요 시 브랜치 삭제

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 로 깔끔하게 이력을 유지하는 게 좋을까요?