Git Convention

Git Convention

git convention이란?

Git을 통해 형상관리를 하면서 git branch 전략과 commit message 규칙을 설정하는 것을 의미한다. 간단하게 말하자면, commit message에 대한 약속이라고 생각하면된다. 

 

Git branch란?

Git에서 독립적으로 어떤 작업을 진행하기 위한 개념을 의미한다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다. 따라서 운영 시 어떤 브랜치를 가지고 갈지 약속하는 것이 git branch 전략이다.

 

Git Convention을 사용하는 이유

Git Convention은 프로젝트를 진행하면서 코드가 독립적으로 안정적으로 개발자들에게 공유될 수 있도록 사용한다. 브랜치를 사용하게 되면 코드는 기능별로 독립적으로 관리되며, Merge Request를 통해 코드를 안정적으로 병합할 수 있다. 또한 commit convention을 지킨 commit message는 Merge Request 단계에서 다른 개발자 동료에게 작성한 코드를 쉽게 이해시킬 수 있게 된다.

 

Git과 SVN의 차이

SVN은 중앙 서버에 소스 코드와 히스토리를 저장하며, Git은 이와 달리 분산형 관리 시스템으로, 소스 코드를 여러 개발 PC와 저장소에 분산에서 저장한다. 따라서 사본을 로컬에서 관리하기 때문에 git의 속도가 더 빠르다. 간단히 예시를 들어서 설명하자면, SVN은 중앙 서버에서 확인하기 때문에 인터넷을 경유해서 가져오지만,  Git은 로컬에서 바로 확인하기 때문에 빠른 속도를 유지할 수 있다. 또한 중앙 서버에 장애가 발생해도 git은 로컬에 커밋할 수 있고, 이 로컬에 저장되어 있는 것을 사용하여 중앙 서버에 복원도 가능하다.

 

1) Branch 전략: Git Flow

Git Flow는 각 개발자들의 병렬적은 작업을 유지하면서 효율적인 배포 체계에 부합할 수 있는 가장 대중적은 branch 전략이다.

 

GIt flow에는 5가지의 브랜치가 존재한다.

- master: 제품으로 출시될 수 있는 브랜치

- develop: 다음 출시 버전을 개발하는 브랜치

- feature: 기능을 개발하는 브랜치

- release: 이번 출시 버전을 준비하는 브랜치

- hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

 

 

그림을 통해 개발 흐름을 설명하자면,

1. 개발자들은 각자 feature branch를 생성해서 작업한다.

2. 작업이 완료되면 develop branch로 병합. develop branch는 모든 개발자들의 작업물이 병합된다.

3. 배포 전에 모든 기능들이 develop branch에 병합 완료되었다면 QA를 위해 develop branch에서 release branch를 생성한다.

4. release branch에서 QA가 진행되며 발생한 버그들은 release branch에서 수정된다.

5. QA가 완료되면 release branch를 master와 develop branch로 병합한다.

6. master branch는 실제 서비스에 배포된다.

7. 운영 단계에서 긴급하게 버그가 발생해 수정해야 할 경우, hotfix branch를 생성해 처리 후 master branch에 병합한다.

 

Merge Request를 통한 Code Review

Git Flow를 사용하면 다른 브랜치로 통합하는 단계에서 코드의 merge가 진행된다. 이때, 직접  merge하는 것이 아니라 merge request를 생성해 동료들의 리뷰를 받은 후, 승인을 거쳐 merge 한다.

 

2) Commit Convention (Code Review에서 Commit Convention을 적용했을 때의 장점)

Merge Request를 통해 동료들에게 코드 리뷰가 요청되면, 동료들은 Merge Request의 커밋 순서를 따라가며 개발자의 개발 흐름을 파악한다.

개발자 동료는 커밋 메시지와 소스코드를 확인하여 해당 커밋의 내용을 파악하고, 의견이 있다면 해당 코드의 라인에 리뷰를 남긴다. 따라서 커밋 메시지를 컨벤션에 맞춰 작성하면 코드 리뷰 시 동료에게 내용을 효과적으로 전달할 수 있다.

 

✔️ Commit Message

작업 중인 로컬에서 git에 반영시킬 때 commit 하면서 해당 커밋에 대한 메시지를 남기는 것이다. 메시지를 동료들이 쉽게 이해할 수 있도록 작성해야 한다.

커밋 메시지의 구조는 크게 3가지로 나뉜다. 

type: 제목 (엔터) body: 본문 (생략가능) (엔터) footer: 꼬리말 (생략가능)

 

✏️ Commit Type

Feature	새로운 기능 추가
Fix	버그 수정 또는 typo
Docs	문서 수정
Style	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
Refactor	코드 리팩토링
Test	테스트 코드, 리팩토링 테스트 코드 추가(비지니스 로직에 변경이 없는 경우)
Chore	빌드 업무 수정, 패키지 매니저 수정, 브랜치 작업
Comment	필요한 주석 추가 및 변경
Design	CSS 등 사용자 UI 디자인 변경
Init	프로젝트 초기 생성
Rename	파일 혹은 폴더명, 리소스 이름 수정하거나 경로를 옮기는 경우
Remove	파일을 삭제하는 작업만 수행하는 경우
Etc	기타

 

Subject Rule

1. 제목은 최대 50글자 초과 X

2. 마침표 및 특수기호 사용 X

3. 첫 글자 대문자, 명령문 사용(과거시제 사용하지 않음)

4. 간결하고 요점적으로 서술

"Fixed" --> "Fix" "Added" --> "Add"

 

Body Rule

1. 한줄 당 72자 내로 작성(제목과 구분하기 위해서 한칸 띄워서 작성)

2. 최대한 자세하게 작성(하지만 선택사항이기에 필수로 작성할 필요는 없음 --> 부연설명이 필요하거나 커밋의 이유를 설명해야할 때 작성)

3. '무엇을', '왜' 변경했는지에 대해서 작성 (무엇, 왜 >>> 어떻게)

 

Footer Rule

1. 유형: #이슈 번호 의 형식으로 작성

2. 이슈 트래커 ID를 작성

3. 여러개의 이슈 번호는 ,로 구분

4. 이슈 트래커 유형은 다음과 같다.

5. 선택 사항임 --> 필수X

 

Issue Tracker

Fixes:	이슈 수정중(아직 해결되지 않은 경우)
Resolves:	이슈를 해결한 경우
Ref:	참조할 이슈가 있을 때 사용
Related to:	해당 커밋에 관련된 이슈 번호(아직 해결되지 않은 경우)

예시)

Footer에 Fixes: #1이라고 작성하고 commit을 할 경우, 자동으로 issue #1과 매칭이 된다.

또한, Resolves: #1으로 이슈를 해결했다고 명시하면 그 이슈는 사라진다.

 

Example

Feature : 작업요청사항 - 기능추가 #1 : 내용정리 - 기능추가 #2 : 내용정리 Link : https://trello.com/

 

Reference

https://devinn.dev/blog/detail.html?id=115 

Blog | Dev.Inn

https://kdjun97.github.io/git-github/commit-convention/

[Git/Github] Commit Convention이란?