<aside> <img src="attachment:455ba932-dd48-426e-9804-6c631068cddd:bracnhh.webp" alt="attachment:455ba932-dd48-426e-9804-6c631068cddd:bracnhh.webp" width="40px" />
| 브랜치 유형 | 내용 |
|---|---|
main |
완성된 버전의 코드를 저장하는 브랜치 |
develop |
개발이 진행되는 동안 완성된 코드를 저장하는 브랜치 |
feature |
작은 단위의 작업이 진행되는 브랜치 |
hotfix |
긴급한 오류를 해결하는 브랜치 |
유형/#이슈번호-what
ex) feat/#30-home-ui, init/#1-add-font
| 카테고리 | 내용 |
|---|---|
feat |
구현 |
mod |
수정 |
add |
추가 |
del |
삭제 |
fix |
버그 수정 |
refacotr |
리팩토링 |
| </aside> |
<aside> <img src="attachment:4e965ee0-c85e-45cc-a4f4-cde50df26a9a:commit.svg" alt="attachment:4e965ee0-c85e-45cc-a4f4-cde50df26a9a:commit.svg" width="40px" />
Commit → [커밋 카테고리/#이슈번호] 커밋 내용 (대문자)
ex) [FEAT/#30] 홈 뷰 구현, [ADD/#1] 폰트 파일 추가
Issues → [FEAT] 제목
ex) [INIT] 프로젝트 기초세팅
Pull requests → [FEAT/#이슈번호] 제목
ex) [FEAT/#6] PR 테스트
| 카테고리 | 내용 |
|---|---|
feat |
기능 (feature) |
fix |
버그 수정 |
docs |
문서 작업 (documentation) |
style |
포맷팅, 세미콜론 누락 등, 코드 자체의 변경이 없는 경우 |
refacotr |
리팩토링 : 결과의 변경 없이 코드의 구조를 재조정 |
test |
테스트 |
chore |
변수명, 함수명 등 사소한 수정 ex) .gitignore |
| </aside> |
<aside> <img src="attachment:7ec811be-ee88-4c73-b75e-98905c6389f8:git.png" alt="attachment:7ec811be-ee88-4c73-b75e-98905c6389f8:git.png" width="40px" />
: 기본적으로 Git Flow 전략을 이용한다. 작업 시작 시 선행되어야 할 작업은 다음과 같다.
< Git Flow >
Issue를 생성한다.
Types 빼고 다 채우시면 좋겠습니다. (급할땐 제외)
Branch를 생성한다.
Add - Commit - Push - Pull Request 의 과정을 거친다.
commit은 최대한 잘게!!
commit시 issue를 연결한다.
commit시 issue를 연결한다.
Pull Request가 작성되면 작성자 이외의 다른 팀원이 Code Review를 한다.
Code Review가 완료되면 Pull Request 작성자가 dev Branch로 merge 한다. → ⭐ merge 후 카톡방에 무조건 말하기 ⭐
merge된 작업이 있을 경우, ‼️다른 브랜치에서 작업을 진행 중이던 개발자는 본인의 브랜치로 merge된 작업을 Pull 받아온다.‼️
