DPI [2-15] 클리핑 마스크 미적용시 [16~20] 문항 오답처리

git_branch_manage.md

@@ -0,0 +1,87 @@
+# 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` 로 깔끔하게 이력을 유지하는 게 좋을까요?