(fork vs branch, 규칙, 프로젝트 유의사항(git 명령어) → 추후 정리하여 md파일에 입력

Repository 관리 방식
위 그림과 같이 공용저장소 기준으로 fork하여 관리하는 방식은 개인 저장소에서 어떤 커밋을 하여도 공용 저장소에는 영향이 없기 때문에 자유롭게 실험이 가능하다는 이점이 있습니다. 하지만 fork를 하지 않고 브랜치를 나눠서 관리하는 방식으로 하면 하나의 저장소에서 이슈와 github projects관리를 하기 때문에 다른 저장소로 이동없이 한 공간에서 작업 및 토의를 할 수 있는 이점이 있었습니다. 우리 팀은 후자의 이점이 더 크다고 생각하여 후자를 택하게 되었습니다. 더불어 전자의 방식은 프로젝트의 규모가 훨씬 더 클때 이점이 더 큰 방식이라고 생각하였습니다.
Repository와 Branch 관리 요약
Repository
- origin (Origin Repository - FEDC1_Zzari-Mongttang_Gidong1)
Branches
- develop
- feature/이슈번호/기능명(각각 맡은 기능별 브랜치)
저장소 관리방식 장단점
우아한형제들 배민프론트개발팀 저장소 관리 방법
여러 저장소 관리 방법들
작업시 규칙
- 함께 공유하는 브랜치(main, develop)에는 push하지 않습니다.
- 핵심 기능에 대하여 다른 팀원에게 리뷰를 받아 approve받습니다.
- approve를 받은 PR은 스스로 merge합니다.
작업시 유의사항
개발시작 전, merge전에
origin 저장소의 최신상태를 가져와서 rebase로 병합하여 반영
git fetch origin
git rebase origin develop