📚 Git에서 Commit(커밋)을 다루는 법
커밋은 Git의 핵심 요소 중 하나이다. 커밋은 staging area의 상태를 버전으로 기록하는 과정이며, 특히, 여러 명이 참여하는 프로젝트에서는 커밋 메시지의 중요성이 더욱 강조된다.
이에, 이번 글을 통해 버전을 기록하고, 이를 통해 더 효과적으로 협업하기 위해 Git에서 커밋을 다루는 방법에 대해 자세히 알아보고자 한다. 또한, 커밋 가이드라인도 알아보며 커밋 작성 시 주의해야 할 사항들에 대해서도 알아보고자 한다.
Commit(커밋)
📌 Commit 방법
Git에서 커밋을 하기 위해서는, 먼저 working directory에 있던 작업 사항들 중 커밋을 원하는 것들에 대해서 git add를 통해 staging area로 옮겨야 한다. 이 후, git commit을 통해 이를 repository로 해당 변경 사항들을 커밋할 수 있다.
cf> workign area와 staging area에 대해서는 이전 글을 통해 더욱 자세히 확인 가능하다.
📌 HEAD의 의미
Git을 사용하다보면 'HEAD'를 자주 볼 수 있었을 것이다. Git의 커밋을 다루기 위해서는 이 HEAD에 대한 명확한 이해가 필요하다.
HEAD는 어떤 커밋 하나를 가리키고 있는 존재로, 보통 가장 최근에 한 커밋을 가리키고 있다. HEAD가 중요한 이유는, HEAD가 가리키는 커밋에 따라 working directory가 다르게 구성되기 때문이다.
만약 HEAD가 최신 커밋보다 더 이전의 커밋을 가리키게 되면, working directory의 내부도 그 과거 커밋의 모습대로 바뀌게 된다.
📌 이전 커밋으로 git reset하기
그렇다면 HEAD를 더 이전에 했던 커밋을 가리키도록 하기 위해서는 어떻게 해야 할까? 이럴 때는 git reset라는 커멘드를 통해 HEAD를 이전 커밋으로 옮길 수 있다. 이 때, commend 맨 뒤에 가고 싶은 커밋의 아이디를 적어주면 된다.
대표적인 예로, git reset --hard라는 커맨드를 보내게 되면 HEAD가 가리키는 커밋에 맞게 working directory가 바뀌게 되고, 결과적으로 우리는 이전 커밋으로 git을 reset할 수 있게 된다.
하지만, --hard옵션을 사용하게 되면 커밋 이후로 working directory에서 했던 내용들이 다 사라지고, 복구할 수 없기에 반드시 주의를 해야한다.
따라서, 밑에서 hard옵션 외에 다른 옵션들도 살펴보며 조금 더 안전하게 git reset을 하는 법에 대해서도 학습해보자.
📌 git reset의 3가지 옵션
앞서 --hard라는 옵션을 살펴보았는데, git reset에는 3가지 --soft와 --mixed라는 옵션도 존재한다.
각 옵션은 Git의 작업 영역 중 몇 개의 영역까지 리셋을 하느냐에 따라 구분되는데, 따라서 원하는 상황에 맞게 옵션을 사용한다면 git reset을 더욱 효과적으로 다룰 수 있게 된다.
| 옵션 | working directory | staging area | repository |
|---|---|---|---|
--soft | 변경 없음 | 변경 없음 | HEAD가 주어진 커밋으로 이동 |
--mixed | 변경 없음 | 주어진 커밋으로 변경 | HEAD가 주어진 커밋으로 이동 |
--hard | 주어진 커밋으로 변경 | 주어진 커밋으로 변경 | HEAD가 주어진 커밋으로 이동 |
💡 cf> git reset을 하면 그 이후의 커밋이 삭제될까?
git reset을 통해서는 이전 커밋으로 되돌아가면, 돌아간 커밋 이후의 커밋들은 삭제된다고 착각하기 쉬운데, 사실은 그렇지 않고 커밋들이 모두 계속 남아있는다.
또한, git reset은 과거의 커밋뿐만 아니라, 현재 HEAD가 가리키는 커밋 이후의 커밋, 즉 더 나중의 커밋으로 돌아가는 것도 가능하니 이 점도 참고하여 git reset을 사용해 커밋 사이를 자유자재로 이동하자.
- cf> 만일 돌아간 커밋 이후의 커밋들의 id를 찾고 싶은 경우
git reflog커맨드를 통해 확인 가능하다.
Commit Guideline
📌 커밋 시 가이드라인
좋은 커밋 관리를 위해서는 아래 2가지 가이드라인을 준수하는 것이 매우 중요하다.
먼저, 하나의 커밋에는 하나의 변경사항만 포함하는게 좋다. 즉, 하나의 커밋에는 하나의 수정 사항 또는 이슈 해결 내용만 포함하는게 좋다. 그 이유로, 여러 변경 사항을 한 커밋에 포함시키면 이후 문제의 원인을 파악하기 어려울 수 있기 때문이다.
또한, 정상 작동하는 코드만 커밋하는 것이 권장된다. 이에, 커밋 전에 코드가 정상적으로 실행되는지 확인하고, 에러 없이 실행되는 코드만 커밋하는 것이 중요하다.
📌 커밋 메시지 작성 시 가이드라인
좋은 커밋 메시지는 프로젝트의 이해도를 높이고 협업을 용이하게 한다. 이에, 많은 개발자들이 주로 통용해서 사용하는 커밋 메시지 작성 가이드라인을 준수하며 커밋 메세지를 작성하는 것이 권장된다.
이에, 그 중에서 많이 통용되고 중요한 커밋 메시지 작성 시 유의할 점들을 몇 가지 정리해 보았다.
-
제목 끝에 온점 사용 금지: 커밋 메시지의 제목 끝에는 온점(.)을 붙이지 않는다. -
제목의 첫 글자는 대문자로: 커밋 메시지의 제목은 첫 글자를 대문자로 작성한다. -
명령조 사용: 커밋 메시지의 제목은 명령조로 작성하는 것이 좋다. (예: "Fix bug" or "Update feature") -
상세 설명 추가: 왜 커밋을 했는지, 어떤 문제가 있었고, 해결책이 어떤 효과를 가지는지를 상세 내용에 기술한다.
Outro
이번 글을 통해 Git에서 커밋을 효과적으로 다루는 법에 대해 살펴보았다.
커밋은 단순히 코드의 변경 사항을 기록하는 것 이상의 의미를 가지며, 프로젝트의 history와 그 진행 상황을 나타내는 중요한 지표이다. 또한, 커밋을 통해 팀원들과의 협업을 원활하게 하고, 프로젝트의 방향을 명확히 할 수 있다.
이러한 Git의 핵심 요소 중 하나인 Commit을 가이드라인에 맞게 올바르게 사용하며, 적재적소에 올바른 커멘드를 통해 다룸으로써 버전 관리를 최적화하고, 협업 능력을 향상시켜 나가보자.
