Git 커밋 메세지를 효율적으로 해야하는 이유 | 깃 커밋 효율적으로 하는 방법

a 코드 한 줄을 이전 commit에서 삭제한 채로 pr을 보냈었다. 지금 프로젝트의 전반적인 페이지를 살펴보며 오류를 잡아가는 중인데, 갑자기 그 코드가 필요해졌다. 그 코드는 구글링을 한참해서 찾았던 코드라 다시 구글링하는 것보다 나의 예전 commit 기록을 보면 쉽게 해결되겠다 싶었다.

그래서 내 깃 그래프를 살펴보았다. main 페이지에서 작업했던 내용이고 특징이 있는 코드라 분명히 기록에서 쉽게 찾을 수 있을 것 같았다. 그런데 왠일이냐… 내가 내 예전 커밋 메세지를 자세히 보는건 오랜만이였는데 a 코드를 적용한 커밋을 쉽게 찾을 수가 없었다.

문제는 너무 큰 기능 변경 단위로 커밋을 한 탓이였다. 나는 커밋 수가 많으면 지저분해보일 것이라고 생각했기때문에 - 1.해당 페이지 마크업 2.해당 페이지 쉽고 필수적인 기능 3. 까다로운 기능 4. 오류 수정 - 이 정도의 크기 단위로 커밋을 하고 있었다. 또, 커밋 메세지가 길면 무조건 안좋다라고 생각하고있었다.

소름돋게 이 날 오후, 스터디방에 커밋 수에 대한 고민을 털어놓았었는데, 한 현직자 분께서 조언을 해주셨었다. 인프콘 2022의 “코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes, 서지연” 강의 추천과 "Squash Merge"를 이용하면 커밋이 깔끔해진다고 이야기해주셨다.
(Squash Merge에 대한 정리는 다음글이 될 것 같다. )
[인프콘 링크] https://www.inflearn.com/course/infcon2022

이 강의섹션의 speaker는 코드 리뷰를 한다는 것은 “코드 변경 크기”, “작업 명확성”, “빠른 속도” 라고 하신다. 이 강의를 볼 땐 ‘아~ 맞어 저 세가지가 중요하지. 나중에 회사에서 협업할 때 다시 체크해야지’ 생각하고 넘어갔었다.

그런데 지금 내 깃 그래프를 보면서 저 세 가지가 코드리뷰가 아니더라도 중요하다는 것을 깨달았다. 내 깃 commit기록은 코드 변경 크기가 너무 큼 -> 큰 작업단위로 명시됨 -> 작업의 명확성이 떨어짐 이렇게 되어 있었던 것이다. 그래서 만든 나조차도 어느 커밋에서 어떤 코드 작업을 했는지 기억하지 못하는 상황이 와버린 것이다.

여러 웹사이트를 찾아보았고 아래 글이 제일 간략하고 눈에 들어왔다. 한번 흝어보길 추천한다.
[참고] https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/?source=post_page-----2d0fc890f59a--------------------------------

위 글에 따르면,

기본:
git commit -m "메세지"
제목, 본문 (디테일)
git commit -m "제목(위 기본처럼 작성)" -m "본문내용"

아래의 네가지를 커밋하기 전에 생각해보라고 한다.

• 왜 이 코드 변화를 했나?
• 이 코드가 어떤 효과를 만들었나?
• 왜 이 코드변화가 필요했나?
• 코드변화와 관련있는게 뭔가?

 

“Make it clear why that change was made, and note if it may be crucial for the functionality or not.”

(왜 그 변화가 만들어졌는지 명확히 하고 기능적으로 중요한지 기록해라)

아래 두가지 커밋메세지가 있다.

1. git commit -m “margin 추가”
2. git commit -m “로고가 겹치는 것을 막기위해 nav안에 margin 추가”

한눈에 봐도 아래가 좋은 커밋메세지라는 게 보인다. 1번과 달리 2번은 몇달이 지난 후에 해당 커밋을 보더라도 어떤 코드변화가 담겨있을지 예상이 간다.

앞으로의 나의 커밋 그래프가 적절한 기능 변경단위 -> 명확한 커밋메세지 -> 미래의 나 혹은 다른 개발자가 봐도 이해가능 이 되길 바라며…

 

 

(이 글은 옵시디언을 통해서 발행되었습니다.)