커밋 메시지가 도대체 무엇이길래? (커밋메시지의 중요성과 협업)

git을 쓰다보면 수없이 많은 commit 메시지를 작성하는 나의 모습을 마주할 수 있다.
제일 처음 git을 접하고 작성한 코드를 저장소에 commit하노라면 무슨 말을 적어야할지 그저 난감할뿐이다.
그나마 한글로 작성하면 조금이라도 더 수월하게 작성해보겠지만, 영어가 어색한 필자는 코드를 마주하는 것보다 더 서운하다.
commit을 하는 횟수가 늘어나고 git을 사용하며 github를 방문하는 횟수가 늘어갈수록,
commit 메시지 창 앞에서 더 오랜 시간을 보낼 수 밖에 없는건 왜일까.
처음 경험한 팀프로젝트 이후 commit 메시지에 한 자 한 자를 어떻게 적어야할지 고민하고, 공부하는 시간이 늘었다.

본래 Git은 분산 버전 관리 시스템으로 프로젝트의 변경 이력을 관리한다.

개발자가 Git을 사용하는 가장 큰 이유는 변경 사항을 추적하고, 작업을 공유하고 협업함에 있을 것이다.
그에 따라 commit 메시지를 작성하는 이유도 함께 살펴봐야 한다.

앞서 본 Git의 사용 목적을 확인할 수 있는 곳은 commit 메시지다.
개발자는 과거의 commit 메시지를 통해 변경 사항을 추적하고 이력을 관리할 수 있다.
commit한 개발자가 당시 어떤 수정을 했는지, 왜 그런 수정을 했는지 만약 commit 메시지에 내용을 남겼다면
독자로 하여금 확인할 수 있는 것이다. 물론, 당사자도 포함해서말이다.

예컨대, 헨젤과 그레텔 같은 것이다.
흘려놓은 빵 조각들이 지나간 길을 안내하는 것이다. 심지어 빵에 당시 상황이 구체적으로 적혀있고,
그 당시로 되돌아갈 수도 있다는 점에선 동화보다도 더 동화같지만 말이다.

방금 말한 당시로 되돌아간다는 것이 ‘롤백’을 의미한다.
commit 메시지는 이력을 남기는 것이다. 그런데 이력만 남기는 것이 아니라, 해당 이력의 시점으로 다시 돌아갈 수 있는 ‘롤백’
의 기능을 제공한다. 프로그램을 개발하고 발전한다는 것이 늘 긍정적인 방향이나 결과만을 의미하진 않기 때문이다.

헨젤과 그레텔의 얘기가 나와서 말이지만, 헨젤과 그레텔은 빵 조각을 통해 본인들의 위치를 공개했다.
commit 메시지도 마찬가지다. 프라이빗이 아닌 퍼블릭 레포지터리라면 참여한 모든 이에게 commit 메시지가 공유된다.
지나온 흔적을 공개한다는 것은 프로젝트에 참여한 모든 사람들에게 변경한 이력을 공개하는 것이다.
이는 프로젝트의 투명성을 제공하고 협업과 리뷰의 과정에서 유용한 정보를 제공하는 역할을 한다.
또한, 본인이 작성한 프로그램의 목적성과 가치를 commit 메시지를 통해서 직, 간접적으로 보여줄 수 있다.
빵 조각을 통해 가고 있는 길이 보이는 것처럼, commit 메시지의 이력들은 현재 프로젝트의 진행 방향이나 목적, 가치를
충분히 보여줄 수 있고, 메시지 안에 적는 내용이 어떤 가치관을 담고 수정하고 있는지를 반영할 수 있다.

커밋 메시지 최적화

commit 메시지를 작성함에 있어 ‘어떤 것만이 정답이다’는 분명히 없겠지만,
유익한 commit 메시지는 분명히 있다. 그러니 유익한 메시지 작성법이 무엇인지 알아보도록하자. 물론 영어를 기준으로 고민해봤다.

1. 제목과 본문 사이에는 공백이 한 줄 들어간다.
   제목 1줄 + 공백 1줄 + 본문 n줄
   
   

docs: Add user registraition feature

Implement user registration from and backend logic. Validate user inputs and store data in the databases. Add registration success page.

모든 경우에 이렇게 작성해야할 필요는 없다.
가령 오타가 나서 간략하게 수정하거나, 시간이 부족해 간단한 수정 후 commit하는 경우도 있어
이러한 경우엔 오히려 한 문장으로 commit 메시지를 작성하는게 더 효율적이기도 하다.
또한, 제목과 본문이 강제 구성사항도 아니다.

그럼에도 앞서 설명한 것처럼 제목과 본문을 구성하고, 사이에 공백을 넣어주면 상당히 유익하다.
이렇게 구성을 하면, $ git log –oneline 이 제목만 보여준다는 장점이 있다.

$ git log --online
docs: Add user registraition feature

1. 제목은 50자 이내로 작성한다.
   

‘이내’라는 말이 반갑다. 영어로 50자 이상을 제목으로만 적으라는 것이었다면 상상이상으로 commit 자체가 고역이었을 것이다.
그러나 동시에, 이내로 적으라는 말은 짧고 굵게 표현하라는 의미라 어쩌면 50자가 짧게 느껴지기도 한다.
제목을 적는다는 것은 장황하게 풀어서 보여줄 필요는 없지만, 제목에 핵심을 담을 수 있도록
매 commit마다 깊은 고민으로 연습해나가야 한다.

1. 타입을 표시하고, 제목의 첫 자는 대문자로 적는다.
   타입(Type): 제목
   
   

커밋 메시지의 제목에는 타입 라벨을 맨 앞에 붙여 작성해 어떤 수정이 이뤄졌는지 가시적으로 나타낸다.

1. 제목 끝에는 . 을 찍지 않는다.
   제목이라 찍지 않는다.
   
   

1. 제목은 과거시제가 아닌 명령어로 작성한다.
   

commit 메시지의 제목을 과거시제가 아닌 명령어로 적는 이유는 git의 Built-in-Convention을 따르는 것이다.
왜냐하면 git은 자동으로 커밋할 때 스스로 명령문을 사용하여 commit하기 때문이다.
이처럼 과거시제가 아닌 명령어로 제목을 작성해두면 자동 메시지 사이에 위치한 commit이 자연스럽게 이어진다.

그러나 본문은 꼭 이 규칙을 따르지 않아도 괜찮다.
제목에서 못다한 얘기를 본문에서 자유롭게 하면 어떨까싶다.

1. 본문은 72자 기준으로 줄 바꾸기

본문을 자유롭게 적으면 좋다고 방금 얘기했지만, 줄바꿈을 해주면 깔끔한 메시지를 연출할 수 있다.
물론 git log 스타일을 지정했다면 자동으로 줄바꿈이 적용돼 로그를 출력하지만, git log만 입력해서는 자동으로 줄바꿈을 지원하지 않는다.

1. 무엇과 왜에 집중해 본문을 작성한다.
   

어떤 변화를 주었는지는 생략할 수 있다. 코드 자체로 설명이 되거나 제목으로 전달되는 경우도 있기 때문이다.
그러나 처음 commit 메시지의 목적처럼 무엇을, 왜 변화했는지 기록해야 당신과 협업하는 당신에게
충분히 전달할 수 있다는 것을 항상 기억해야 한다.

git은 하위 명령어가 많은만큼 커맨드라인을 수용하는 것이 현명하다. 충분히 숙지하고 사용하자.

커밋의 유형과 키워드 활용

커밋 메시지를 작성함에 있어 커밋 메시지의 유형(Type)과 키워드(Keyword)를 알고 있는 것이 유용하다.
왜냐하면 커밋 메시지의 유형과 키워드는 변경 사항에 대해 명확하게 전달하고 자신의 커밋 메시지에 대한 의미를 부여하기 때문이다.
아래는 일반적인 커밋 메시지의 유형과 키워드다.

작성 예시

feat: Add user authentication functionality

커밋 관리를 통한 팀 협업

결국 지금 이 글을 작성하게 된 가장 큰 이유가 여기 있지 않을까싶다.
사실, 이전까지 다른 직업에서나 혹은 아주 사소한 협업조차 경험해보지 못했을 당시엔 commit의 중요성을 전혀 알지 못했다
commit 관리를 통한 팀 협업은 프로젝트의 개발과 관리를 원할하게 진행하기 위해 정말이지 중요한 요소인데
그 이유를 정리해두는 것이 앞으로 commit을 작성하고 관리함에 있어 도움이 될 것 같다.

commit을 통해 개발자들은 프로젝트의 변경 사항을 추적하고 이력을 관리할 수 있기 때문에 각 commit은 특정 작업 또는 수정을 대표하고, 이를 통해 개발자들은 진행 상황을 파악하고 이전 버전과의 차이점을 확인할 수 있다.
commit 메시지를 통해 개발자는 변경 사항에 대한 정보를 공유할 수 있고 다른 팀원과 소통할 수 있다. 명확하고 의미 있는 commit 메시지는 다른 개발자들이 변경 사항을 이해하고 검토하는데 도우며 협업 과정에서 오해와 혼동을 줄인다.
commit을 기반으로 한 코드 리뷰는 팀의 코드 품질을 향상시킨다. 다른 개발자들은 커밋된 변경 사항을 검토하고 피드백을 제공할 수 있고, 코드의 일관성, 가독성, 효율성 등을 평가할 수 있다.
여러 개발자들이 동시에 작업할 때 커밋을 통해 충돌을 방지하고 해결할 수 있다. commit을 기반으로한 브랜치 관리와 병합은 효율적인 협업과 코드 통합을 지원하며, 다양한 기능과 수정 사항을 안전하게 관리할 수 있다.
commit을 통해 프로젝트의 이전 상태로 쉽게 롤백할 수 있다. 문제가 발생했을 때 이전 작업 내용으로 복구하는 것은 프로젝트의 안전성과 신뢰성을 유지하는데 돕는다.