[Git] 의미있는 commit 메시지와 깔끔한 history

의미있는 커밋 메시지 작성 방법과 깔끔한 history 유지하기

Github Repository의 커밋 내역만으로 프로젝트의 전체 흐름을 파악할 수 있다.

 

• 의미있는 커밋 메시지 작성 방법
• merge 전략 3가지

---

Commit 메시지 구조

type(타입) : title(제목)

body(본문, 생략 가능)

Resolves : #issue, ...(해결한 이슈 , 생략 가능)

See also : #issue, ...(참고 이슈, 생략 가능)

 

Commit 메시지 규칙

1. 커밋 타입 지정

• FEAT : 새로운 기능 추가
• FIX : 버그 수정
• DOCS : 문서 수정 및 추가
• STYLE : 코드 스타일 관련 변경(코드 포매팅, 세미콜론 누락 등)
• REFACTOR : 코드 리팩토링
• TEST : 테스트 코드, 리팩토링 테스트 코드 추가
• CHORE : 빌드 task 수정, 패키지 매니저 수정(.gitignore 수정 같은 경우)

 

2. 제목과 본문은 빈 행으로 분리

 

3. 제목 행은 50자로 제한

 

4. 제목 행의 첫 글자는 대문자로 시작

• read the docs ❌
• Read the docs. 🟢

 

5. 제목 행 끝에 마침표 X

• Read the docs. ❌
• Read the docs  🟢

 

6. 제목은 명령형으로 작성

• Docs are ready ❌
• Read the docs  🟢

 

7. 본문에는 추가 or 변경 내용과 이유를 적는다.

• 무엇을 추가 or 변경 했는지와 그 이유를 적는다.
• '어떻게' 는 지양한다.

---

CLI 로 commit 메시지 작성 예시

 

1.

$ git commit

 

2.

vi를 통해 제목, 본문을 작성한다.

주석 부분을 통해 현재 커밋중인 레포와 브랜치를 확인하자

---

Git Merge

 

 

git merge 전략은 3가지가 있는데 어떤 방식을 선택하느냐에 따라서 commit 내역이 기록되는 방식이 달라진다.

 

 

why?
commit history는 왜 중요하고 merge 전략과 무슨 상관이 있는가?

 

커밋은 원칙적으로 의미있는 하나의 변경사항을 의미한다.

 

따라서 커밋 내역만 보고도 어떤 사항이 어떤 이유로 변경되었는지 쉽게 파악할 수 있어야 한다.

 

많은 시니어 개발자들이 커밋 메시지에 대한 중요성을 언급하는 이유도 짧은 커밋 메시지만 보고도 언제, 어떻게 코드가 변경되었는가를 한번에 알고 싶기 때문이다.

 

---

커밋 히스토리가 중요한 이유

 

1. 버그가 언제 터졌는지 파악하기 쉽다.

 

2. 레거시 코드를 수정해야할 때

 

---

3가지 Merge 전략 

 

3가지 머지 전략 모두 두 개의 브랜치를 합친다는 의미는 동일하다.

대신에 머지 방법과 커밋 히스토리의 기록을 각각 다르게 가져간다.

 

 

1. Create a Merge Commit

 

 

가장 일반적인 머지 전략이다.

 

경우 1

1. feature/#1 브랜치에 Feat: 결제 기능 추가 라는 커밋이 추가되었다.
2. feature/#1 브랜치가 master 브랜치에 머지되면서 삭제된다.

-> master 브랜치는 feature/#1 브랜치의 커밋내역이 그대로 입력되고, 히스토리와 브랜치 가지는 그대로 남아있다.

 

장점

• 어떤 브랜치에서 어떤 커밋이 진행되어 어떻게 머지가 되었구나 라는 자세한 정보를 얻을 수 있다.

 

단점

• 히스토리가 너무 자세히 남기 때문에 브랜치의 개수가 많아지거나 머지 횟수가 잦아질수록 히스토리 그래프의 가독성이 떨어진다.
  
  
• 그리고 원칙적으로 커밋은 의미있는 변경 사항의 최소 단위이지만 오타 수정과 같은 자잘한 커밋을 하는 경우도 정말 많다.
  따라서 이러한 커밋들이 많아지면 오히려 히스토리의 가독성을 해치게 된다.

 

 

CLI 사용법

$ git switch master		# master 브랜치(병합 받을 브랜치로 옮긴다)
$ git merge feature/#3  	# 현재 브랜치에 feature/#3 브랜치를 병합한다

merge 명령어를 입력한 후 vi창이 나타날 것이다.

여기에 commit 메시지를 입력할 수 있다.

 

 

2. Squash and Merge

 

 

Squash 는 여러 개의 커밋을 하나로 합치는 기능을 말한다.

즉, 이 기능은 머지할 브랜치의 커밋을 전부 하나의 커밋으로 합친 뒤 타겟 브랜치에 커밋하는 방식으로 머지를 진행한다.

 

따라서 Sqash and Merge 를 통해 발생하는 커밋은 실질적인 머지로 인해서 생성된 머지 커밋이라기 보다는 그냥 다른 브랜치의 변경 사항을 하나로 뭉쳐놓은 커밋이라고 볼 수 있다.

 

그래서 Squash and Merge 전략은 머지할 브랜치에 적용된 커밋을 하나의 커밋으로 요약할 수 있다.

 

 

경우 2

1. issue #7 은 결제 내역 조회 기능을 개발하자는 내용의 이슈이다.
2. Git flow를 적용해서 결제 내역 조회 기능을 개발하는 브랜치인 feature/#7 을 생성한다.
3. feature/#7 에 다양한 커밋이 쌓이게 된다.
4. feature/#7 의 개발이 끝나고 develop 브랜치로 머지를 요청하는 PR를 생성한다.
5. 이때 머지 방식은 Squash and Merge 로 PR을 생성한다. (PR 제목 : 결제 내역 조회 기능 개발 #3)
6. 생성된 PR에는 feature/#7 에 커밋된 히스토리가 모두 기록되므로, 코드 충돌을 확인한 후 Merge 한다.
7. 이때 Merge 메시지로 <결제 내역 조회 기능 개발 #3> 을 입력해 커밋 내용을 요약한다.

 

장점

•  커밋 히스토리를 추가된 기능별로 단순 명료하게 관리할 수 있다.

단점

• 자세한 커밋 내역을 볼 수 없다고 하는데 Github 와 같이 사용한다면 커밋 메시지에 #3 으로 PR이 링크되기 때문에 해당 PR과 연결된 커밋 내역을 모두 확인할 수 있어서 큰 단점이 아니라고 생각된다.

 

 

CLI 사용법

$ git switch master			# master 브랜치(병합 받을 브랜치로 옮긴다)
$ git merge --squash feature/#3  	# 현재 브랜치에 feature/#3 브랜치를 병합한다

 

 

3. Rebase and Merge

 

 

Git 의 Rebase(리베이스) 기능을 사용하여 브랜치를 머지하는 것이다.

 

Rebase 란 브랜치 히스토리들의 베이스를 변경하는 기능이다.

feature/#3 브랜치의 변경사항이 마치 master 브랜치에서 변경된 것처럼 바꿀 수 있다는 것이다.

 

리베이스는 머지된 브랜치의 커밋을 모두 살려놓기 때문에 커밋 내역은 전부 알 수 있다.

 

하지만 해당 커밋이 기록된 브랜치가 어느 시점에 머지되고 삭제되었는지는 알 수 없다.

 

쉽게 말해서 리베이스를 사용하여 브랜치를 머지하게 되면 feature/#3 에서 발생한 모든 작업사항이

마치 처음부터 master 브랜치에서 작업한 것처럼 변경할 수 있다.

 

 

장점

• 브랜치의 히스토리를 완전히 엎어버릴 때 유용한 것 같다. (사실 언제 사용할지는 감이 오지 않는다.)

 

단점

• 머지 충돌에 매우 취약하다.
  머지할 브랜치의 히스토리 자체를 그대로 복사해서 대상 브랜치의 히스토리에 덮어버리기 때문에 충돌이 발생하게 되면 모든 커밋에 대해서 하나씩 충돌이 발생한다.
  
  
• 만약 PR을 날렸는데 수십, 수백개의 커밋에 충돌이 발생했다면 리베이스로 한게 아닌지 의심해보자.

---

Git 히스토리는 중요해요