자! 깃 마스터해서 프로젝트 해보자고!!!

학습시간 09:00~02:00(당일17H/누적858H)

---

◆ 학습내용

팀프로젝트를 위한 Git & GitHub 정보

---

1. GitHub 협업

(1) Repository

• Git 저장소 = 버전 관리되는 코드/파일 모음
• GitHub에서 Repository는 팀의 공식 협업 공간
• 각자 로컬에서 작업한 뒤, Remote Repository에 Push → PR → Merge

💡 Repository 이름 짓는 팁

• 소문자 + 하이픈() 사용
• 프로젝트 목적 또는 도메인을 명확히
• 예시
  • pill-detection
  • ocr-uploader
  • supervision-lab
  • image-preprocessing

(2) Branch

• Git의 작업 공간 분기선
• 여러 개발자가 충돌 없이 동시에 작업 가능

💡 브랜치 사용 이유

• 메인 코드 보호
• 실험적 기능 격리
• 버그 수정, 기능 추가 등의 명확한 기록
  

(3) 팀리더가 해야할 것?

1. Repository 생성
2. Collaborator 초대
3. master 브랜치 보호 설정
   • settings → branches → add branch ruleset
   • name: master → require a pull request before merging → create
4. develop 브랜치 생성
5. project board 생성 → add item → 할일 입력 → add assign
6. Pull requests 확인
7. Merge

---

2. Branch Strategy

(1) 정의

• 협업에서 브랜치 네이밍과 머지 흐름을 일관되게 정하는 약속
• 코드 품질 관리 + 충돌 최소화 목적

(2) 대표 브랜치 구조

브랜치명	용도	설명
main	제품 배포 버전	가장 안정된 코드
develop	개발 통합	모든 기능 통합 전용
feature/*	기능 개발	ex. feature/login, feature/upload
bugfix/*	버그 수정	ex. bugfix/image-crop-error
hotfix/*	긴급 배포	운영 환경 버그 긴급 대응용

브랜치 구조 예시

main
 └─ develop
     ├─ feature/login
     ├─ feature/image-upload
     ├─ bugfix/preprocess-error
     └─ hotfix/deploy-crash

• 모든 작업은 develop을 기준으로 파생
• main에 직접 작업 금지

(3) 브랜치 네이밍 규칙

• 접두어 + 기능명 형태
• <브랜치타입>/<기능 또는 이슈명>
• 예시
  • feature/ocr-training
  • bugfix/dataloader-shuffle
  • hotfix/deploy-issue

브랜치타입	의미
feature	새로운 기능 개발
bugfix	코드 내 문제 수정
hotfix	운영 환경 오류 긴급 대응
release	배포 준비용 (optional)
refactor	리팩토링, 성능 개선
chore	설정, 문서, 기타 잡작업

(4) 실전 브랜치 흐름 예시

# 1. develop 기준 새 브랜치 생성
git checkout develop
git pull origin develop
git checkout -b feature/image-upload

# 2. 작업 후
git add .
git commit -m "feat: implement image upload endpoint"
git push -u origin feature/image-upload

# 3. PR 생성 → 리뷰 → Merge

(5) conflict 방지

# develop 최신 코드 반영
git fetch origin
git rebase origin/develop

• 항상 PR 전에 리베이스
• 충돌 발생 시 직접 해결 후 -continue

(6). 브랜치 전략 필요성

이유	설명
코드 충돌 방지	팀원 간 작업 분리
코드 리뷰 가능	PR로 품질 관리
이력 추적 용이	기능별 변경 내역 파악
운영 안정성 확보	main은 언제나 배포 가능 상태 유지

---

3. Semantic Versioning

(1) 버전 형식

버전은 보통 다음과 같은 형식으로 작성

v[MAJOR].[MINOR].[PATCH]

항목	의미
MAJOR	큰 변화 (호환 깨짐)
MINOR	새로운 기능 추가 (호환 유지)
PATCH	버그 수정, 사소한 개선

예시

• v1.0.0: 최초 안정 릴리즈
• v1.2.0: 기능 추가
• v1.2.1: 버그 수정
• v2.0.0: 구조 변경, 호환성 깨짐

(2) 접미어 확장

테스트 단계나 릴리즈 전 버전은 다음처럼 표기한다:

형식	의미
-alpha	초기 테스트
-beta	베타 테스트
-rc.1	릴리즈 직전 후보
-dev	개발 중 내부 버전

예시

• v1.2.0-beta
• v2.0.0-rc.1

(3) Git에서 태그로 관리하기

git tag v1.2.0
git push origin v1.2.0

• 특정 커밋에 버전 이름을 붙여 관리
• GitHub에서 Releases 탭으로 버전 기록 가능

(4) 버전별 변경 로그 예시

.md 파일 예시

## [v1.2.0] - 2025-05-22
### Added
- 이미지 업로드 기능
### Fixed
- bbox 크기 오류 수정