Git guideline

Git-Flow

Git-Flow를 사용해 유연한 프로덕트 관리를 돕습니다.

기본적으로 2개의 브랜치를 유지합니다.(master, develop)

master: Release 되어 출시될 제품의 브렌치 (라이브 서버는 해당 브렌치를 바라봅니다)
develop: 다음 버전을 현재 개발중인 브랜치

추가적으로 유연하게 브랜치를 관리합니다.(feature, hotfix)

feature: develop 브랜치에서 신규 기능 개발을 위할 때 사용, feature/SOMETHING 의 명명으로 사용
hotfix: 현재 출시된 버전에서 버그를 수정할 때 사용

다음 버전의 배포준비를 위해 release branch를 사용합니다(release)

release: 다음 버전 배포 이전에 RC(Release Candidate)가 적용됩니다. (개발 서버는 해당 브렌치를 바라봅니다)

Commit Guidelines

Commit message를 활용하여 배포 자동화 및 semantic versioning에 활용합니다

semantic-release를 활용하기 위해 Angular commit guideline을 따릅니다.

Types

feat: 새로운 기능 추가
fix: 버그 수정
docs: 도큐멘테이션 변경
style: 코드에 지장 없는 스타일 변경(공백, 세미콜론 추가, etc)
refactor: 기능적으로나 버그를 수정한 리펙토링
perf: 퍼포먼스 향상을 위한 코드 추가
test: 테스트코드 추가
chore: 빌드 프로세스 또는 도큐먼트 생성과 같은 툴 및 라이브러리 변경

Example

쇼핑(아이템 선택, 장바구니 담기 등) app을 개발한다고 가정,

feat: 장바구니에 아이템 담기 기능 추가
fix: 장바구니에 아이템이 안담기는 버그 수정
docs: 프로젝트 readme.md 변경 등
style: 코드에 세미콜론을 빼먹음, 연산자 사이에 공백 추가 등
refactor: 장바구니 담기 코드가 비효율적이어서 효율적인 코드로 변경(내부적으로 변경, 외부적으론 차이가 없음)
perf: 장바구니 담기는 속도가 너무 느려서 최적화 등
test: 장바구니에 잘 담기는지에 대한 테스트 코드 작성
chore: redux를 mobx로 교체 등

Commit Guidelines

Commit 규칙을 설정해 commit graph를 관리합니다.

큰 주제의 기능은 feature/FEATURE로 브랜치를 생성 후 작업을 진행합니다.
작업을 시작하기 전에 Git issue를 생성합니다.
Git issue를 연관된 project와 연결하고 내용에 맞는 라벨들을 기입합니다.
하나의 이슈는 되도록 하나의 커밋으로 합니다.
커밋 그래프는 최대한 단순하게 가져갑니다.
서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.
리뷰어에게 꼭 리뷰를 받습니다.(merge가 가능해도 진행하지 않습니다)

References