[필독] Git 규칙

Git Flow

• 개발할 때 사용하는 default branch
• 이 브랜치는 무결해야 하며, 강제로 force push하거나 허락 없이 바로 merge할 수 없도록 branch protection rule이 설정되어 있습니다.

develop 브랜치에 병합하기 전 확인 사항

• 작업 한 브랜치는 develop 브랜치와 병합 충돌이 발생해서는 안됩니다.

• 병합 충돌이 발생하지 않더라도, 병합하기 전 rebase 후 병합해야 합니다.
• git graph를 깔끔하게 관리하기 위함

# local develop branch

git fetch origin develop
git rebase origin/develop

git checkout feature/your_branch

git rebase develop

# if conflict 
# shell로 작성하는 것이 gui를 쓰는것 보다 좋다.
git add .
git rebase --continue

# 리베이스를 중지하고 싶다면
git rebase --abort

# orgin branch에 push 시 --force 옵션이 없을 경우 커밋이 꼬일 수 있으므로 
# 반드시 --force 옵션을 줘야 함

git push --force

• 작업한 branch의 작업물이 브라우저 상에서 콘솔 상 오류가 없어야 합니다.

• 작업한 branch의 작업물 코드 상 lint error(빨간 줄)이 발생하면 안됩니다.

• 불필요한 console.log를 제거해야 합니다.

[Git] Git Rebase란? (feat. git-flow 히스토리를 더 이쁘게 만들기)

안녕하세요. 이번에는 Git rebase에 대해 정리하겠습니다! 는 두 개의 공통 Base를 가진 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 branch의 base를 옮기는 작업입니다. 용어 그대로 베이스를 다시 설정하는 작업입니다. git merge는 공유 branch에 대한 변경사항을 즉각 대응하기 어렵습니다. 반면에 를 사용한다면, 동료 개발자들이 올린 commit들의 수정사항을 내가 작업하고 있는 branch에 즉각 반영할 수 있습니다.

https://seosh817.tistory.com/240

• 기능을 개발하거나, 버그를 수정해야 할 때에는 develop 브랜치로부터 checkout을 한 뒤 작업을 진행합니다.
• 커밋 컨벤션 우선순위와 동일하게 기능 개발을 하면서 관련 버그가 수정되었다면, feature가 더 높은 우선순위를 가질 수 있습니다.

• 배포를 위한 브랜치입니다.

• 커밋 prefix는 다음과 같으며, 위쪽이 우선순위가 더 큽니다.
• feat : 기능 상의 변화가 있을 때 (제품 코드 수정 발생)
• fix : 버그 수정
• docs : 문서 추가 및 삭제, 변경 (코드 수정 X)
• style: 코드 형식 및 정렬, 주석 변경
• refactor: 코드 리팩토링
• chore: 그 외 나머지

• 커밋 메시지는 다음과 같이 작성합니다.

• PR을 작성할 때는 prefix로 #{jira_ticket_number}를 사용합니다. 그리고 나머지 부분은 issue와 동일한 제목을 붙입니다.

Pull Request관련

• PR 리뷰 기간은 PR 이 올라온 뒤 24시간 이내로 리뷰를 진행

• 이슈 단위 최소화
• 처음 이슈 등록시 수정 범위가 너무 커지지 않도록 이슈 범위를 잡아주세요.
• 코드의 수정량이 200줄 근처로 맞춰주세요 (필수는 아니지만, 최대한 지키려고 노력합시다)

• 커밋 단위와 수정 단위를 일치

• 코드 가독성 신경쓰기