01. Git Convention (commit활용법)

Git에 관련된 개념과 기본적인 사용법은 이 링크를 참고하길 바란다.

2025.02.13 - [Sparta(JAVA심화3기) - TIL/Chap.01] - Chap.01 : 특강 - Git 그리고 PR(Pull Request) - TIL

 

이 글에서는 팀 프로젝트를 진행하는데 있어서 활용하거나 썼던

• Git Convention (commit활용법)
• Git Merge
• Git Branch 전략 (Git flow)
• + 프로젝트 팀 - Repository, Organization, Team 생성 및 팀원 권한 등록

 등을 다루도록 하겠다.

 

 

Git Convention (Commit 활용법)

---

Git 커밋 메시지는 일관성 있게 작성해야 팀원들이 작업 내용을 빠르게 파악할 수 있다.

커밋 메시지의 기본 구조는 다음과 같다.

type(타입) - title(제목)

body(본문, 생략 가능)

Resolves #issueNo, ...(해결한 이슈 , 생략 가능)’

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

 

기본 규칙

• 제목과 본문을 빈 행으로 구분
• 제목은 영문 기준 50글자 이하
• 첫 글자는 대문자로 작성
• 제목 끝에 마침표X
• 제목은 명령문으로 사용, 과거형X
• 본문의 각 행은 영문 기준 72글자 이하
• 본문은 어떻게보다는 무엇과 왜에 대해 작성

 

커밋 메시지 타입

커밋 타입은 변경사항의 성격에 따라 다르게 작성한다. 가장 자주 사용되는 feat와 fix 외에도 다양한 타입이 있다.

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)
• design : 사용자 UI 디자인 변경 (CSS 등)
• test : 테스트 코드, 리팩토링 테스트 코드 추가
• refactor : 코드 리팩토링 (Production Code)
• build : 빌드 파일 수정
• ci : CI 설정 파일 수정
• perf : 성능 개선
• chore : 빌드 업무 수정, 패키지 매니저 수정
• rename : 파일 혹은 폴더명 수정
• remove : 파일 삭제

해당 작업에 대하여 상세한 기록 (영한은 자유롭게) ex) “feat : subject entity 생성”

 

관련 이슈

---

커밋이나 PR에 포함될 이슈 템플릿을 작성할 때는 다음과 같은 항목을 포함하여 상세히 기록한다.

• 해결 시 : Closes, Fixes, Resolves 등을 사용하여 해결된 이슈 번호를 기록
• 참고 시 : Ref, Related to, See also 등을 사용하여 참고 이슈 번호를 기록

Issue Template

## Description

여기에 이슈에 대한 설명을 적어주세요.

## Progress

- [ ] todo1
- [ ] todo2
- [ ] todo3

## Etc

기타 참고 사항이 있다면, 적어주세요.

 

 

Pull Request 작성 규칙

---

1. PR을 남기기 전
   • develop으로 푸시하기 전에  테스트를 완료하고 문제가 없음을 확인한 후 PR을 남긴다.
   • 기능 단위로 작업이 완료되었을 때 PR을 남긴다.
2. Reviewer 지정
   • PR을 남길 때, 코드 리뷰를 받을 팀원을 Reviewer로 지정한다.
   • Reviewer가 승인하지 않으면 Merge하지 않는다.
3. Merge 후 슬랙 알림
   • PR 승인 후 develop 브랜치에 Merge하고, 슬랙 채널에 @here 태그를 사용하여 해당 PR이 Merge되었음을 알리고, 다른 팀원들이 develop 브랜치를 Pull하도록 안내한다.

Git 브랜치 명명법

PR Template

PR을 남길 때에는 아래와 같은 템플릿을 사용하여 변경 사항을 정확히 기재한다.

## Description
변경 사항 및 관련 이슈에 대해 간단하게 작성해주세요. 어떻게보다는 무엇을 왜 수정했는지 설명해주세요.

Resolves: #(Issue Number)

## PR Type
어떤 변경 사항이 있나요?
- [ ] 새로운 기능 추가
- [ ] 버그 수정
- [ ] 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
- [ ] 코드 리팩토링
- [ ] 주석 추가 및 수정
- [ ] 문서 수정
- [ ] 테스트 추가, 테스트 리팩토링
- [ ] 빌드 부분 혹은 패키지 매니저 수정
- [ ] 파일 혹은 폴더명 수정
- [ ] 파일 혹은 폴더 삭제

## PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.

- [ ] 커밋 메시지 컨벤션에 맞게 작성했습니다.
- [ ] 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트)

 

위의 규칙들을 참고하여 커밋 메시지 작성, Pull Request 관리 시 일관된 방식으로 작업을 진행하였다.

---

정리 - 체계적인 Git 사용이 원활한 협업을 만든다.

Git은 단순한 버전 관리 도구를 넘어, 효율적인 협업을 가능하게 하는 핵심 요소이다.
이번 글에서는 프로젝트를 하면서 다뤘던 실무에서 자주 사용하는 Git Convention, Merge 전략, Git Flow, PR 관리 방법에 대해 이야기 했다.

 ✔️ 일관된 Git 커밋 컨벤션을 유지하면, 팀원들이 변경 사항을 쉽게 이해할 수 있다.
 ✔️ PR 작성 및 코드 리뷰 프로세스를 명확히 하면, 코드 품질이 향상되고 버그를 조기에 발견할 수 있다.
 ✔️ Git Flow와 브랜치 전략을 적용하면, 협업 중에도 깔끔한 코드 관리를 유지할 수 있다.

팀 프로젝트에서 Git을 올바르게 활용하면 개발 생산성이 향상되고, 코드의 가독성과 유지보수성이 좋아진다.

앞으로도 Git을 적극적으로 활용하여 더 효율적인 협업과 안정적인 프로젝트 운영을 할 수 있도록 하겠다.

참고 자료

https://jane-aeiou.tistory.com/93

[Git] 좋은 commit message 작성법