회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
Git 커밋 메시지는 코드 변경 사항을 요약하여 전달하는 역할을 합니다. 만약 개발자들이 서로 다른 방식으로 커밋 메시지를 작성하면 메시지의 가독성이 떨어지고, 문제 발생 시 이력을 추적하기 어려워집니다. 따라서 프로젝트 시작 전에 Git 커밋 메시지 컨벤션(규약)을 정하는 것이 중요한데요. 이번 글에서는 Git 커밋 메시지 컨벤션의 중요성과 커밋 메시지 작성 방법을 알아보고, 이를 편리하게 자동화할 수 있는 방안에 대해 소개하겠습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
Git 커밋 메시지는 코드 변경 사항을 요약하여 전달하는 역할을 합니다. 만약 개발자들이 서로 다른 방식으로 커밋 메시지를 작성하면 메시지의 가독성이 떨어지고, 문제 발생 시 이력을 추적하기 어려워집니다. 따라서 프로젝트 시작 전에 Git 커밋 메시지 컨벤션(규약)을 정하는 것이 중요한데요. 이번 글에서는 Git 커밋 메시지 컨벤션의 중요성과 커밋 메시지 작성 방법을 알아보고, 이를 편리하게 자동화할 수 있는 방안에 대해 소개하겠습니다.
Git 커밋 메시지 컨벤션(Git Commit Message Convention)이란 프로젝트 참여자들이 일관된 형식의 커밋 메시지를 작성하기 위한 규칙을 말하며, 간단히 줄여서 Git 커밋 컨벤션이라고도 합니다. 현재 여러 개발자들 사이에서 관습적으로 통용되는 가이드라인이 있지만, 각 프로젝트에 따라서 별도의 규칙을 만들어 적용하기도 합니다.
Git 커밋 메시지 컨벤션을 지키는 것은 프로젝트 관리와 협업에 있어서 중요한 부분입니다. 정해진 규칙에 따라 커밋 메시지를 기재함으로써 개발자들이 서로의 작업을 이해하고 효율적으로 대처할 수 있는 프로젝트 환경을 만들 수 있습니다. 특히 다음 두 가지 이유로 Git 커밋 메시지를 작성하면, 프로젝트를 보다 효율적이고 안정적으로 관리할 수 있습니다.
일관된 커밋 메시지의 형태를 유지하면 가독성을 높일 수 있으며, 이에 따라 다른 개발자의 작업 내역이나 변경 사항을 쉽게 파악할 수 있게 됩니다. 또한 코드 리뷰 및 버그 수정 과정에서 불필요한 의사소통 과정을 간소화하여, 프로젝트 관리에 들어가는 시간도 줄일 수 있습니다.
Git 커밋 컨벤션을 지키면 일관된 커밋 메시지를 통해 소스 변경 이력을 효율적으로 추적할 수 있습니다. 이를 통해 문제 발생 시 더 빠르게 원인을 찾아 수정할 수 있으며, 전반적인 프로젝트 안정성을 높일 수 있습니다.
현재 일반적으로 사용되고 있는 Git 커밋 메시지 기본 포맷은 다음과 같습니다.
이 포맷에서 <type>은 변경 사항의 유형 중 하나를 나타냅니다. 예를 들어, feat (새로운 기능), fix (버그 수정), docs (문서 변경), style (스타일 수정), refactor (코드 리팩토링), test (테스트 코드 수정), chore (기타 작업) 등이 있습니다.
다음으로 <description>에는 변경 작업의 제목이나 간단한 요약을 작성합니다. 보통 이 부분은 50자 이내로 간결하게 작성하는 것이 좋으며, 영문인 경우 대문자로 시작하고 마침표를 사용하지 않는 것이 일반적입니다.
<body>는 선택 사항으로서 작업 내용이 복잡하거나 상세한 내용을 남겨야 하는 경우에만 작성합니다. 필요한 경우 여러 줄로도 작성할 수 있으며, 보통 한 줄당 약 72자 이내로 작성하는 것이 좋습니다.
<footer> 역시 선택 사항이며, 코드 작업과 관련된 이슈 번호 또는 참조 링크 등을 추가합니다. 특정 작업이나 이슈를 해결한 경우에는 일반적으로 "Closes #작업번호 또는 이슈번호" 같은 형태로 기재합니다.
예를 들어, 웹 개발 프로젝트에서 사용자 프로필 페이지를 추가한 작업을 한 경우 아래와 같은 방식으로 Git 커밋 메시지를 작성할 수 있습니다. 일반적으로 제목줄(<type>: <description>)과 <body>, <footer> 사이에는 한 줄씩 공백을 둡니다.
참고로 위 예시의 경우 조금 더 상세한 단위로 커밋을 분리할 수 있습니다. 다만 커밋을 어느 정도로 쪼개야 하는지에 대해서는 프로젝트 규모와 개발자 간의 작업 방식에 따라 달라질 수 있으므로, 이 부분도 Git 커밋 메시지 컨벤션을 정할 때 미리 조율해두는 것이 좋습니다.
Git 커밋 메시지를 수정하는 방법은 커밋을 Push 하기 전과 Push 한 후로 나눠볼 수 있습니다. 커밋을 Push 하기 전에는 터미널 창에서 git commit –amend를 입력하여, 아래 그림과 같이 가장 최근에 만든 커밋 메시지를 수정할 수 있습니다.
참고로 터미널에서 vi/vim 편집기를 이용하는 경우에는 a 또는 i로 커서를 삽입하여 수정하면 됩니다. 그리고 수정을 완료한 후에는 ESC를 누른 후, :wq 를 입력하여 변경 사항을 저장해야 합니다. (vi/vim 편집기의 기본적인 명령어는 Git 커밋 메시지 수정 전에 미리 익혀두는 것을 권장합니다.)
만약 수정해야 하는 Git 커밋 메시지가 가장 최근 커밋이 아닌 경우에는 git rebase -i HEAD~숫자를 입력하여 수정할 커밋 메시지를 선택할 수 있습니다. 여기서 숫자는 최근까지 실행된 커밋 중 몇 개까지 살펴볼 것인지를 말합니다. 예를 들어, 2를 입력하면 최근 커밋보다 이전에 커밋된 2개의 Git 메시지를 수정할 수 있습니다.
rebase로 커밋 수정 화면에 들어가면 각 커밋 앞에 pick이 적혀있는데요. 수정하고자 하는 커밋 앞의 pick을 reword로 변경한 뒤 :wq로 저장하면 자동으로 해당 커밋을 수정할 수 있는 창이 열립니다. Reword 외에 pick 대신 edit를 사용할 수도 있습니다. 이 경우에는 git rebase –continue를 사용하여 수정하고자 하는 다음 커밋으로 이동할 수 있습니다. 모든 커밋들에 대한 수정이 끝나면 자동으로 rebase 과정이 종료됩니다.
커밋을 push 한 후에는 커밋 메시지를 수정하는 것을 권장하지 않습니다. 그 이유는 다른 개발자들이 해당 변경 사항을 이미 pull 받았을 수 있기 때문인데요. 만약 이를 무시하고 강제로 push 하면 충돌이 발생할 수 있으니, 이런 상황은 될 수 있으면 피하는 것이 좋습니다. 다만 그럼에도 불구하고 반드시 수정해야 하는 경우라면 앞서 설명한 방법으로 커밋 메시지를 수정 후 git push --force를 입력하면 됩니다.
Git 커밋 메시지를 기계적으로 작성할 때가 있는데, 이걸 굳이 손으로 일일이 써야 하나?라는 생각이 듭니다. 만약 Git 커밋 메시지를 자동으로 생성하거나, 모든 팀원이 컨벤션을 제대로 지키도록 강제하는 도구가 있다면 보다 효율적으로 Git 커밋 이력을 관리할 수 있으니 말입니다. 이와 관련해 Git 커밋 메시지 작성을 자동화하고, 규칙을 강제할 수 있는 방법을 정리해 봤습니다.
가장 간단하게 적용해 볼 수 있는 방법은 바로 Git 커밋 메시지 템플릿을 설정하는 방법입니다. 템플릿을 사용하면 메시지의 기본 구조를 제공함으로써 일관된 커밋 메시지를 유도할 수 있게 되는데요. Git 커밋 메시지 템플릿을 설정하려면, 기본 구조가 적힌 템플릿 파일(ex. git_commit_template.txt)을 생성한 후, git config commit.template 명령어로 해당 템플릿 파일을 config에 등록하면 됩니다.
현재 Git 커밋 메시지를 자동으로 생성하고 관리하기 위해서 다양한 자동화 도구들이 나와있는데요. 대표적으로 Git 커밋 메시지를 검사하여 컨벤션을 따르는지 확인해 주는Commitlint, Git 훅(hook)을 설정하여 커밋 및 푸시 전에 자동화된 작업(ex. 커밋 메시지 검사, 코드 포맷팅 등)을 설정할 수 있는Husky와 같은 도구들이 있습니다.
개인적으로 Git 커밋 자동화 도구로 Husky를 주로 사용하고 있는데요. Husky는 프로젝트 폴더에서 npm을 사용(npm install husky --save-dev)하여 설치할 수 있습니다. 설치가 완료되면, 프로젝트 루트 디렉터리에 .huskyrc 파일을 생성하고 Git 훅을 설정합니다.
그러면 이제 .huskyrc에 설정된 대로 커밋이나 푸시하기 전에 Git 커밋 메시지 관련 작업이 자동으로 실행됩니다. 덧붙여 Husky는 방금 말한 Manual 방식 외에, 아래 그림과 같은 명령어로 설치하는 방법도 있으니 참고하시길 바랍니다.
프로젝트의 안정성을 높이기 위해 깔끔하고 일관된 커밋 메시지는 필수입니다. 앞서 살펴봤듯이 메시지의 가독성을 통해 소스 변경 이력을 빠르게 추적하여 문제를 해결할 수 있기 때문입니다. 또한 다른 개발자들의 작업 내역과 프로젝트 변경 사항을 보다 쉽게 이해할 수 있게 됨으로써, 팀원 간 협업이 원활하게 이루어지게 할 수 있습니다.
이처럼 중요한 커밋 메시지를 효율적으로 작성하려면 템플릿을 설정하거나, Commitlint, Husky 같은 자동화 도구를 활용하는 방법들이 있습니다. 아직 프로젝트에서 Git 커밋 메시지 자동화 도구를 사용하지 않았다면 오늘 소개한 활용 방법들을 검토해 보셔도 좋겠습니다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
좋아요
댓글
공유
공유
32.5K
