브랜치 전략 - Git flow
우리팀은 이번에 아래 내용정도로만 브랜치 전략을 사용할 예정
브랜치 종류 / 설명
Git-flow에는 5가지 종류의 브랜치가 존재한다. 항상 유지되는 메인 브랜치들(main develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, hotfix)이 있습니다.
•
main : 제품으로 출시될 수 있는 브랜치
•
develop : 다음 출시 버전을 개발하는 브랜치 (main에서 뽑아서 작업)
•
feature/(작업하는기능) : 기능을 개발하는 브랜치 (develop에서 뽑아서 작업)
•
fix/(수정하는문제) : develop 브랜치에서 문제가 생긴 경우 (develop에서 뽑아서 작업)
•
hotfix/(수정하는문제) : main 브랜치에서 문제가 생긴 경우 (main에서 바로 뽑아서 작업)
작업 순서
1.
처음에는 main와 develop 브랜치가 존재합니다. 물론 develop 브랜치는 main에서부터 시작된 브랜치입니다.
2.
develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다.
3.
새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다. feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 됩니다.
4.
기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다.
5.
충분한 검증 이후엔 main 브랜치로 develop 브랜치를 merge 합니다.
merge시 주의사항
•
merge는 PR을 통해서 합니다.
•
merge의 책임은 merge한 사람이 집니다.
•
merge는 rebase and merge로 합니다.
git pull --rebase origin develop
그리고 force push
Plain Text
복사
개발 도중에는 main이 맨 앞에 뜨면 번거로움
Default 브랜치는 develop으로 바꿔줍시다. 나중에 좀 체계가 생기면 main을 얹어봅시다.
깃 커밋 컨벤션
커밋 컨벤션은 팀마다 다르고 조금 더 디테일하게 작업할 수 있지만 우리팀은 이정도로 해보도록 합시당
커밋 메시지 구조
제목, 본문, 꼬리말 구조
type: subject
body
JavaScript
복사
커밋의 제목
type: 내용 형태 (띄어쓰기 주의)
•
예) feat: 로그인 버튼 구현
커밋 type
•
feat : 새로운 기능 추가
•
fix : 버그 수정
•
docs : 문서 수정
•
style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
•
refactor : 코드 리펙토링
•
chore : 빌드 업무 수정, 패키지 매니저 수정 (하기 싫은 일)
본문 ← optional
•
본문에 쓸 내용이 없다면 작성하지 않아도 된다.
•
본문은 한 줄 당 72자 내로 작성한다.
•
본문 내용은 양에 구애받지 않고 최대한 상세히 작성한다.
•
본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명한다.
참고 자료
Git | git 커밋 컨벤션 설정하기 → 너무 좋은 누군가의 벨로그이슈 템플릿 + PR 템플릿
먼저 백엔드 측에서도 해줘야하는 것 (주희도 읽어볼 것)
이슈 만들기
이슈탭을 잘 작성했다면 이렇게 잘 뜨겠죠?
기능 이슈를 만들어봅시다.
TODO와 무엇을 해야하는지, 특이사항은 무엇인지 작성합니다. (이슈를 올리면 수정 가능함)
여기에 TODO는 우리의 칸반보드에 들어가는 하나하나가 됩니다.
PR을 통해서 이슈를 제거하는 방법
closed #이슈번호를 사용하면 이슈를 바로 닫을 수 있어요.
만약 이슈가 해결이 되지 않았다면 closed를 쓰지 않고 #이슈 번호만 작성해주세요.