커밋하기 — 정의, 포맷팅 규칙 및 Git 작업

Git에서 커밋이란

Git에서 커밋은 특정 시점의 프로젝트 파일 상태를 저장하는 객체입니다. 각 커밋에는 추적 중인 모든 파일의 스냅샷, 부모 커밋 참조 및 메타데이터가 포함됩니다. 다른 버전 관리 시스템과 달리 Git은 콘텐츠 주소 지정 스토리지를 사용합니다 — 각 객체는 콘텐츠의 SHA-1 해시로 식별됩니다.

개발자가 변경사항을 커밋하면 Git은 트리 객체(파일 구조), 부모 커밋 해시, 작성자, 커미터, 날짜 및 메시지를 저장하는 커밋 객체를 생성합니다. 이 객체는 변경 불가능합니다 — 생성된 후에는 해시를 변경하지 않고 커밋을 수정할 수 없습니다. 이 변경 불가능성은 프로젝트 기록의 무결성을 보장합니다.

# 변경사항 스테이징 및 커밋
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# 커밋 세부정보 보기
git log --oneline -3
git show HEAD

# 모든 변경사항 스테이징 후 한 번에 커밋
git commit -a -m "Update dependencies to latest versions"

커밋은 방향성 비순환 그래프(DAG)를 형성하며, 각 새 커밋은 이전 커밋을 참조합니다. 이를 통해 기록 탐색, 변경사항 되돌리기 및 코드베이스의 진화 분석이 가능합니다. Git DAG 구조를 이해하는 것은 고급 커밋 작업의 기초입니다.

변경사항을 올바르게 커밋하는 방법

Git의 커밋 프로세스는 두 단계로 구성됩니다: 스테이징 영역(인덱스)에 변경사항 추가 및 커밋 생성. 스테이징 영역을 통해 개발자는 작업 디렉토리에서 많은 파일이 변경되었더라도 커밋에 포함할 특정 변경사항을 선택할 수 있습니다.

원자성 규칙은 좋은 커밋의 핵심 원칙입니다. 각 커밋은 하나의 논리적 변경사항을 포함해야 합니다. 개발자가 버그를 수정하고 코드를 리팩토링하는 경우 — 이는 두 개의 별도 커밋이어야 합니다. 원자적 커밋은 코드 리뷰, 변경사항 롤백 및 기록 분석을 단순화합니다.

커밋하기 전에 코드에 디버그 출력, 주석 처리된 블록 또는 우발적 변경사항이 남아 있는지 확인해야 합니다. 이를 위해 git diff --cached 명령이 사용되며, 커밋에 정확히 무엇이 포함될지 표시합니다. git status를 통한 추가 확인은 스테이징 영역의 파일 목록을 표시합니다.

• 변경사항 확인 — git diff --cached로 커밋에 포함될 내용 확인
• 품질 확인 — 커밋 전에 코드가 린터와 테스트를 통과해야 함
• 메시지 작성 — 변경 목적에 대한 명확한 설명
• 스테이징된 파일 확인 — git status로 파일 목록 확인

커밋 메시지 작성 규칙

커밋 메시지는 미래의 개발자를 위한 변경사항 문서입니다. 좋은 메시지는 무엇이 변경되었고 왜 변경되었는지에 대한 질문에 답합니다. Conventional Commits 규칙(Angular 팀, 2016)은 많은 프로젝트의 표준이 되었으며 형식을 정의합니다: 유형(범위): 설명.

좋은 커밋 메시지는 헤더(최대 50자)와 본문(선택사항, 줄당 최대 72자)으로 구성됩니다. 헤더는 명령형으로 작성됩니다: “Add”가 아니라 “Added”나 “Adds”가 아닙니다. Capitalization과 헤더 끝의 마침표는 사용하지 않습니다 — 이는 국제적인 Git 규칙입니다.

나쁜 메시지: “fix things” 또는 “update” — 정보를 전달하지 않습니다. 한 달 후에는 개발자가 무엇이, 왜 변경되었는지 이해할 수 없습니다. 좋은 메시지: “fix(payment): handle timeout in stripe callback” — 무엇이 어디서 수정되었는지 즉시 명확해집니다.

커밋 시 흔한 실수

개발자, 특히 초보자는 커밋할 때 흔히 실수를 범합니다. 가장 흔한 것은 수십 개의 변경사항이 혼합된 너무 큰 커밋입니다. 이러한 커밋은 부분적으로 되돌릴 수 없으며 코드 리뷰가 고통스러워집니다.

두 번째로 흔한 실수는 나쁜 커밋 메시지입니다. “fix”, “update”, “changes” 또는 “wip”와 같은 메시지는 미래의 개발자에게 컨텍스트를 제공하지 않습니다. 6개월 후에는 아무도 무엇이 수정되었는지 기억하지 못할 것입니다. 규칙은 간단합니다: 1년 후에 기록을 보며 특정 변경사항을 찾으려고 하는 자신을 상상해보세요.

세 번째 실수는 컴파일되지 않거나 작동하지 않는 코드를 커밋하는 것입니다. 커밋 후에는 코드가 최소한 컴파일되어야 합니다. 빌드를 깨뜨리지 않는 것은 공유 브랜치에 대한 모든 커밋의 기본 요구사항입니다. 이를 위해 커밋 전에 빌드와 테스트를 실행합니다.

네 번째 실수는 기밀 데이터를 커밋하는 것입니다. API 키, 비밀번호 및 토큰은 Git 기록에 포함되어서는 안 됩니다. 비밀이 이미 커밋된 경우, 새 커밋에서 제거하는 것만으로는 충분하지 않으며 git filter-branch 또는 BFG Repo-Cleaner를 통해 전체 기록에서 삭제해야 합니다.

커밋 작업의 고급 기술

Git은 커밋 기록 관리를 위한 도구를 제공합니다. 가장 유용한 것 중 하나는 git commit --amend로, 마지막 커밋을 새 변경사항으로 보완하거나 메시지를 수정할 수 있습니다. 개발자가 파일 포함을 잊었거나 메시지에 오타가 있는 경우 편리합니다.

# 마지막 커밋 메시지 수정
git commit --amend -m "fix(auth): correct token validation logic"

# 마지막 커밋에 누락된 파일 추가
git add missed-file.txt
git commit --amend --no-edit

# 마지막 3개 커밋에 대한 인터랙티브 리베이스
git rebase -i HEAD~3

인터랙티브 리베이스는 기록을 다시 쓰는 강력한 도구입니다. 커밋 결합(squash), 메시지 변경(reword), 재정렬(reorder) 및 커밋 삭제(drop)가 가능합니다. 그러나 리베이스는 기록을 변경하므로 아직 원격 저장소에 푸시되지 않은 로컬 커밋에만 사용됩니다.

커밋을 취소하는 두 가지 방법이 있습니다. git revert는 이전 커밋의 변경사항을 취소하는 새 커밋을 생성합니다 — 기록을 보존하는 안전한 방법입니다. git reset은 기록에서 커밋을 제거합니다 — 커밋이 이미 푸시된 경우 위험합니다. 팀 개발에서는 게시된 커밋을 취소하기 위해 git revert만 사용합니다.