깃 컨벤션 맞추기

 

KT AI, TIKITAKA 캠페인

 

1. 중요한 깃 컨벤션

 

개발자들은 수많은 협업을 수행하면서 그들이 지닌,

그들만의 컨벤션이 존재합니다.

그러한 컨벤션들은 시행착오를 거쳐가면서 보편적인 모듈로 자리잡습니다.

 

지금은 깃 컨벤션에 대해서 이야기 해봅시다!

 

협업을 할때는 깃 컨벤션이 매우 중요합니다!

왜 중요할까요? 이유는 간단합니다.

 

아래 커밋 메세지를 보도록 합시다.

이 얼마나 성의 없는 커밋 메세지 인가요

회원탈퇴 기능 수정

(너무 대충 작성한 커밋 메세지)

 

 

 

 

 

아래의 커밋 메세지는 어떠한가요?

너무나도 친절한 커밋메세지에 기분이 날아갈것만 같습니다.

[feat]: 회원탈퇴 기능 수정

[목적]: 기존 hard-delete 방식 대신, soft-delete 방식을 적용하여 기능 수정을 하기 위해서.  

[목표]: soft-delete 방식으로 회원탈퇴를 구현하여, 유저가 물리적으로 삭제되는 것이 아닌,
	   상태값으로 탈퇴여부를 관리하여, 유저 계정 복구에 대비.  

[달성도]: 

  - soft-delete 구현 완료.  

  - 멤버 테이블에 탈퇴여부 상태값 추가 완료.  

[기타]: DB 과부화를 방지하기 위해서, 탈퇴 회원은 30일 이후 자동 삭제되도록 처리할 필요가 있음.

(좋은 예시의 커밋메세지)

 

 

이처럼 협업에서 커밋메세지를 잘 적는다면,

코드리뷰를 할때나, pr을 보낼때, 모든 작업자들이

내가 왜 이런 코드를 작성했는지 이해하는데 많은 도움이 됩니다.

물론 나중에 내가 내 코드를 다시보더라도 큰 도움이 됩니다!!

 

 

---

 

2. 깃 컨벤션 규칙을 정해두자

우리는, 협업시 중요한 깃 컨벤션을 맞추기 위해서 노력해야 합니다.

그래서 깃 컨벤션 규칙을 아래와 같이 맞추려고 합니다!

 

저도 이번글을 포스팅하고 앞으로 팀 프로젝트에서 제가 작성한 깃컨벤션을 참고해서

팀 프로젝트를 진행하려고 합니다!!

 

 ✅ 커밋 유형

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 추가/수정 (README 등)
• style: 코드 포맷팅, 세미콜론 누락 등 코드 의미에 영향을 주지 않는 변경
• refactor: 코드 리팩토링 (기능 변화 없음)
• perf: 성능 향상을 위한 코드 변경
• test: 테스트 코드 추가/수정
• chore: 빌드 프로세스 수정, 패키지 매니저 구성 등
• ci: CI 설정 변경 (GitHub Actions, Jenkins 등)
• revert: 이전 커밋 되돌리기

 

 

🔧  커밋 메시지 구조

[type]	제목
[목적]	왜 이 작업이 필요한가?
[목표]	이 작업으로 무엇을 달성하려고 하는가?
[달성도]	현재 커밋에서 해결된 사항은 무엇인가?
[기타]	참고해야 할 사항이나 남은 작업은?

 

 

📋 커밋 예시

 

코드 수정

[fix]: Fix incorrect query in user profile API


[목적]: 특정 조건에서 잘못된 프로필 데이터가 반환되는 문제가 있음.

[목표]: 정확한 데이터를 반환하도록 쿼리 수정.

[달성도]: 

  - 쿼리 수정 완료.

  - API 테스트 통과.

[기타]: 캐싱 로직 추가 검토 필요.

 

 

 

 

코드 리팩터링

[refactor]: Refactor user profile service for better maintainability

[목적]: 기존 서비스 로직이 복잡하여 유지보수가 어려움.

[목표]: 서비스 로직 분리 및 가독성 개선.

[달성도]: 

  - UserProfileService 리팩토링 완료.

  - 중복 코드 제거.

[기타]: 기존 로직의 테스트 커버리지 보강 필요.

 

 

‼ 반드시 이걸 지킵시다!

1. 커밋 작성 기준

 

커밋마다 작업을 논리적으로 나누고,

각 커밋이 작업의 목적과 결과를 명확히 나타내야 해요!

 

1) 커밋의 단위

  작업의 논리적 단위로 나눔

  하나의 커밋은 하나의 논리적 변경 사항(예: 새로운 기능, 버그 수정)이 들어가야 한다!

  너무 많은 변경 사항을 하나의 커밋에 포함하면 안됩니다!!!

 

  큰 작업은 여러 단계로 분리:

  예: 새로운 기능 개발 시, 초기 설정, 서비스 로직 추가, 테스트 코드 작성 등으로 나누기

 

2) 커밋 메시지의 역할

  커밋 메시지 제목만 읽어도 작업의 목적과 결과를 바로 이해할 수 있어야 함.

  바디는 제목과 관련된 정보를 작성하고,

메시지만 보고도 어떤 것이 변화되었는지 손쉽게 파악이 가능해야 한다!