[Git] 다시 정리하는 GitHub Commit 메시지

코드를 수정하거나 기능을 추가할 때 우리는 보통 커밋(Commit) 을 남기게 돼요.

저도 처음에는 커밋이 뭔지 잘 몰라서, 그냥 "저장 버튼 같은 건가?" 싶어서 무심코 Commit 버튼만 꾹 눌렀던 기억이 있답니다 😅

 

그러다 개발 공부를 도와주던 선배가
“커밋 메시지도 규칙이 있다." 라고 말해줘서 알게되었어요.

 

그때부터 커밋 메시지를 좀 더 잘 쓰려고 찾아보게 되었고, 오늘은 제가 정리한 GitHub Commit 메시지 규칙 (Conventional Commits) 을 소개해드리려고 합니다! 🚀

 

1. Conventional Commits란 무엇인가요? 🤔

• 간단히 말하면 "커밋 메시지 작성 약속" 입니다. 날마다 하는 커밋에 규칙을 정해놓으면, 누가, 언제, 무엇을 왜 고쳤는지 커밋 로그만 봐도 파악이 가능해져요.

 

2. GitHub Desktop으로 Commit → Push → Pull Request → Merge 하기 튜토리얼 ✨

GitHub를 사용하다 보면 로컬에서 작업한 내용을 커밋하고, 원격 저장소에 푸시한 뒤, 최종적으로 Pull Request(PR)를 통해 메인 브랜치에 합치는 과정이 꼭 필요합니다.

 

GitHub Desktop을 활용해 이 과정을 하나씩 차근차근 따라가 보겠습니다.

 

1️⃣ Commit 하기

Commit 하기

작업한 파일을 저장하고 나면 GitHub Desktop 화면 왼쪽 하단에 Commit to develop 버튼이 보입니다.

이 버튼을 눌러주면 현재까지의 변경 사항이 로컬 저장소에 기록됩니다.

• Summary 부분에 Commit 메시지는 꼭 작성해주기 (작업 내용을 간단히 요약)
• Commit을 했다고 해서 GitHub에 올라간 건 아님 (아직은 내 컴퓨터 안에만 저장된 상태)

Commit이 끝나면 상단에 Push origin 버튼이 활성화됩니다. 이제 이 버튼을 눌러 원격 저장소로 올려줍니다.

 

Push origin = 내 로컬 작업을 깃허브 서버(origin)로 올리는 것 (업로드)

 

2️⃣ Push 후 Pull Request 생성 준비

Push 후 Pull Request 생성 준비

Commit을 푸시하면 Github Desktop에서 자동으로 브랜치 상태를 확인합니다.

 

만약 내가 작업 중인 develop 브랜치의 변경 내용을 main 브랜치에 합치고 싶다면,
Preview Pull Request 버튼이 나타납니다.

 

이 버튼을 클릭하면, 두 브랜치(main과 develop)를 비교해서
어떤 코드가 추가되거나 수정되었는지를 미리 확인할 수 있는 화면이 열립니다.

 

이 버튼은 말 그대로 "이제 GitHub에 Pull Request를 열 준비가 되었다!"라는 뜻이에요.

 

Preview Pull Request = 올린 브랜치를 다른 브랜치에 합치기 전에 변경 사항을 미리 확인하는 것 (머지 미리보기)

 

3️⃣ 변경 사항 확인하기

변경 사항 확인하기

Pull Request를 만들기 전에, GitHub Desktop에서 변경된 내용을 미리 확인할 수 있습니다.

파일을 수정했다면 초록색/빨간색으로 표시가 됩니다.

• 🔴 빨간색 → 삭제된 부분
• 🟢 초록색 → 새로 추가된 부분

그리고 화면 왼쪽 하단에 Able to merge라는 메시지가 뜨면, 충돌 없이 문제 없이 머지가 가능하다는 의미입니다.

 

4️⃣ GitHub에서 Pull Request 열기

이제 GitHub 웹사이트로 넘어가서 본격적으로 PR을 작성해봅시다.

GitHub에서 Pull Request 열기

 

1. PR 제목을 작성합니다. (보통 작업 내용을 요약)
2. PR 설명(Description)에 세부 작업 내용을 적어줍니다.
   • 무엇을 수정했는지
   • 왜 수정했는지
   • 리뷰어가 알아야 할 사항

이 과정을 통해 협업자들이 변경 내용을 쉽게 이해하고 리뷰할 수 있습니다.

 

5️⃣ Pull Request Merge 하기

Pull Request Merge 하기

리뷰가 끝나고 문제가 없다면, Merge pull request 버튼을 클릭합니다.
그러면 develop 브랜치에서 작업한 내용이 최종적으로 main 브랜치에 반영됩니다.

 

작업이 끝난 뒤에는 브랜치를 삭제하거나 새로운 기능을 위한 브랜치를 다시 만들어서 작업을 이어가면 됩니다.

 

✅ 여기까지가 Commit → Push → Pull Request → Merge 의 전체 흐름이에요.
GitHub Desktop과 GitHub 웹을 오가면서 이 과정을 반복하면 협업 프로젝트도 훨씬 깔끔하게 관리할 수 있습니다. 👍

 

3. 커밋 타입(type)의 종류와 & 의미

타입	의미	예시 메시지
feat	새로운 기능	feat: 사용자 회원가입 기능 추가
fix	버그 고침	fix: 로그인 오류 처리
docs	문서 수정	docs: README 설치 부분 보완
style	코드 스타일 변경	style: 공백 정리, 세미콜론 추가
refactor	코드 구조 개선 (기능 변화 없음)	refactor: 중복 로직 함수로 분리
perf	성능 개선	perf: 이미지 압축 최적화
test	테스트 코드 추가/수정	test: 유닛 테스트 작성
build	빌드 설정/의존성 변경	build: 라이브러리 버전 업데이트
chore	기타 자잘한 작업	chore: gitignore 수정