커밋하기 전에 무조건 pull을 받자
pull을 받고 conflict이 난다면 무조건 해결하고 올리자!
깃허브 규칙
- dev 브랜치에 PR 날리기(main에 바로 merge 절대 금지)
- issue, milestone 작성한 후 기능 개발
- 기능단위별로 commit하기
Git Branch 전략
- main : 배포할 어플리케이션을 업로드한다.
- dev : 새로운 기능과 버그 수정을 한다.
- feature: 도메인 별로 feature branch를 생성하며 작업을 수행 후 dev 브랜치로 병합한다.
feature/openAPIfeature/user
- 빠른 프로젝트 완성을 위해 refactor, fix, release 등은 따로 두지 않고 feature 브랜치로만 진행한다. 대신 commit 메시지를 기능별, 리팩토링 별로 꼼꼼하게 남긴다.
깃헙 커밋 규칙
| 작업 타입 |
작업내용 |
| feature |
새로운 기능 구현 |
| update |
해당 파일에 새로운 기능이 생김 |
| add |
없던 파일을 생성함, 초기 세팅 |
| bugfix |
버그 수정 |
| refactor |
코드 리팩토링 |
| fix |
코드 수정 |
| move |
파일 옮김/정리 |
| del |
기능/파일을 삭제 |
| test |
테스트 코드를 작성 |
| gitfix |
gitignore 수정 |
| script |
build.gradle 변경 |
| rename |
파일 이름 변경 |
| readme |
리드미 |
예시) feature: 로그인 기능 구현