개발 관련 협업 규칙

Task 작업 순서	작업 내용
1. 이슈 등록 & 브랜치 생성	담당 Task에 대한 이슈 생성 및 이슈에 대응하는 브랜치 생성
2. 브랜치에서 개발 진행	생성된 브랜치에서 개발 진행
3. 커밋 작성 및 PR 생성	작업 완료 후 PR(Pull Request) 생성
5. 피드백 반영 및 수정	코드 리뷰 피드백 반영해 코드 수정
6. Merge 수행	승인 후 develop 또는 main 브랜치로 병합

기본적으로 git flow 전략을 따릅니다.

Git Flow를 사용하는 이유
1. 작업 브랜치의 명확한 구분과 관리
master, develop, feature, release, hotfix로 명확하게 구분하여 작업 위치를 쉽게 파악 가능
2. 협업에 최적화된 워크플로우
여러 개발자가 동시에 작업할 수 있으며, feature 브랜치를 통해 충돌을 최소화하고 PR과 코드 리뷰로 품질 향상
3. QA와 배포 프로세스의 명확화
relese 브랜치에서 QA를 충분히 거치고, 배포 시 master와 develop에 동시에 반영하여 일관성 유지
4. 안정적인 버그 수정 지원
긴급 버그 발생 시 hotfix 브랜치로 빠르게 수정하고, master와 develop에 동시에 반영하여 안정성 유지
5. 명확한 릴리즈 관리
배포된 버전은 tag로 관리하여 v1.0.0, v1.0.1처럼 버전 추적이 용이
6. 실험적인 기능 개발에 유연함
메인 브랜치에 영향 없이 feature 브랜치에서 안전하게 실험적 기능 개발 가능

브랜치 종류

브랜치 종류 설명 용도 및 특징 보호 설정

main 배포 가능한 최종 버전 관리 모든 개발이 완료되고 테스트가 끝난 코드만 Merge - 직접 push 금지
- PR만으로 병합 (승인 시 가능) | | develop | 개발 중인 기능들이 모이는 최상위 브랜치 | 개별 feat 브랜치에서 개발이 완료되면 PR을 통해 병합 | - 직접 push 금지
- PR만으로 병합 (승인 시 가능) | | feat | 새로운 기능 개발을 위한 브랜치 | 기능 단위로 생성하여 독립적으로 개발 진행 | 없음 | | hotfix | 긴급 수정 사항 반영 | 배포된 코드에서 발생한 버그 수정 및 QA 피드백 반영 | 없음 |

브랜치 종류	설명	용도 및 특징	보호 설정
main	배포 가능한 최종 버전 관리	모든 개발이 완료되고 테스트가 끝난 코드만 Merge	- 직접 push 금지

브랜치 전략

다음 분기 규칙을 따릅니다.

type/#{이슈번호}/{페이지(있을 경우)}/{기능명}

feat/#이슈번호/페이지명(camelCase)/기능명(두 단어 이상 "-" 이용)
design/#이슈번호/페이지명(camelCase)/기능명

// 브랜치 전략 예시
main
	ㄴ develop
		ㄴfeat/#1/loginPage/kakao-oauth

Merge 전략

Merge 상황	Source 브랜치	Target 브랜치	Merge 방식	설명
기능 개발 완료 시	feature	develop	Squash Merge	여러 개의 커밋을 하나의 커밋으로 압축하여 이력 관리가 간결해짐
최종 배포 전 병합 시	develop	main	Rebase Merge	커밋 히스토리를 정돈하고, 직렬화된 형태로 깔끔하게 유지

Issue

하나의 Issue는 하나의 목표를 가지는 최소 단위로 생성

[ Issue ] 로그인 UI 만들고, 유효성 검증 로직 추가 및 로그인 API 연결

[ Issue #12 ] 로그인 페이지 UI 구현
[ Issue #13 ] 로그인 입력 유효성 검증 로직 추가
[ Issue #14 ] 로그인 API 연결 및 에러 처리