[GitHub]깃린이를 위한 깃허브 사용법(협업ver)
혼자 프로젝트를 하면 컨벤션이 중요하지 않을 수 있지만(아님.중요함) 다른 사람들과 함께 프로젝트를 진행할 때는 컨벤션 및 그라운드 룰을 정하고 그에 맞추어서 진행하는 것이 매우 매우 중요하다.
협업 시의 git flow를 간단히 정리해보고자 한다.
- issue 파기
💭이슈란?: TO DO LIST 작업할 항목들을 정리하고, 담당자(Assignee)및 작업 유형(Labels)설정을 하는 것
2.안드로이드스튜디오 or issue 에서 branch 파기
devleop에서 branch팔 것 (main은 함부로 건들이지 않는다.)
develop branch는 항상 최신화 시켜야함. git pull origin develop
branch 이름은 내가 구현할 기능 이슈 라벨/#이슈 번호-작업 이름 으로 보통 작성.
ex. feat/#10-homeapi :10번이라는 이슈에서 feat(신규 기능을 추가하거나 기존 기능의 동작, 정책을 변경)하고 home api를 연동하는 작업을 진행
라벨 설정
3.내가 담당한 기능 작업 코드 작성
중간 중간 commit push를 해주는 것이 좋다.
*commit 할 때도 컨벤션을 지키기
커밋 유형 한줄 소개 설명
feat 새로운 기능 구현 신규 기능을 추가하거나 기존 기능의 동작, 정책을 변경
fix 버그 수정 버그, UI 오류, 오타, 명세와의 불일치 등을 수정
refactor 리팩토링 기능 변경 없이 코드 구조를 개선하여 가독성, 유지보수성, 성능을 향상
add 파일 추가 기능/설정과 무관한 단순 리소스(이미지, 폰트 등) 추가
delete 파일 삭제 불필요한 코드, 파일, 리소스 제거
style 스타일 수정 UI 변경 대응, 코드 스타일 수정 등 간단한 작업
docs 문서 작업 코드 동작에 영향을 주지 않는 문서(README, 주석 등) 수정
chore 개발 환경 빌드, 의존성, CI/CD, SDK 설정 등 개발 환경 및 생산성 관련 작업
init 프로젝트 초기 세팅 프로젝트 또는 모듈의 초기 설정
4.branch에서 pr 작성
5.리뷰어의 approve or rc(수정) 받기
6.리뷰 반영하기-> 다시 3의 과정 반복
7.develop branch에 merge
confilct을 방지하기 위해서는 중간 중간 누군가가 develop에 merge했다고하면 pull받는게 좋음!(git merge origin/develop)
*단 내 로컬에서 작업중이라면 merge가 불가능하므로 작업중인 코드 commit후에 변경사항을 받아와야함.
*깃에 push 하기 전에는 항상 build가 잘 되는지 실행해보고 올릴 것.
8.merge가 완료된 branch는 삭제
*branch가 계속 쌓이면 관리가 어려워짐.
