커밋을 잘 쓰자

상현·2023년 12월 19일
1

git

목록 보기
7/7
post-thumbnail

어제 새벽.. 잠들기 전에 JIMPIT TO FRONT-END 첫 번째 세션 영상을 보았다. 아주 좋은 말씀들을 많이 해주셔서 해당 세션 마지막 슬라이드에 강연을 해주신 김태곤님의 블로그가 있길래 들어가서 구경을 해봤다.

그 중 FE로 취업하기 전에 알았으면 좋았을 것들이라는 포스트를 보던 중 정곡에 찔리는 부분이 있었다..

커밋 로그
... 중략
상당히 많은 지원자들은 개인 프로젝트의 경우 히스토리 관리를 전혀 하지 않는다는 사실을 깨달았다.
main 또는 master 브랜치의 커밋 로그에는 온갖 의미 없는 커밋 메시지가 가득했다. "임시 저장"이라거나 "Fix bugs", "update", "." 같은 있으나 마나 한 메시지도 심심찮게 보였다.
... 중략
형식만 지킨 "Update: abc.js" 라는 메시지보다는 "버튼을 클릭했을 때 대화창이 나타나지 않는 문제를 수정"과 같이 형식은 따로 없더라도 의미가 충분한 메시지가 훨씬 더 좋다고 생각한다.

완전 나에게 하는 이야기 같았다. 실제로 팀프로젝트에서는 나름 지키려고 하지만 개인 프로젝트에서는 귀찮으니 그냥 막 지었다. 이런게 안좋은 습관이라는 것을 알면서도 귀찮음이 이겨버려서..

하지만 이렇게 채용에 관여하시는 분들이 본다고하니 아무리 개인 프로젝트라도 커밋 메시지를 더 잘 작성해야 겠다.

한 커밋에는 한 가지 문제만

위의 강연에서도 커밋과 관련된 이야기를 해주셨다. 한 커밋에는 한 가지 문제만 해결하라는 건데, 이 얘기도 아주 정곡을 찔렸다.

실제로 프로젝트를 하다보면 여기저기서 바꿨으면 좋겠는 코드들이 보이게 된다. 예를 들어, A라는 기능을 수정하고 있는데 B라는 기능의 디자인이 살짝 어긋난게 보였고, 코드 한줄이면 수정이 가능한 것을 보았다.

그래서 나는 참지 못하고 B의 디자인 까지 수정하고 git comit -m "A기능 수정" 이라는 커밋 메시지를 작성했다.

하지만 git을 사용하는 이유가 추적관리가 용이하기 위함인데, 이렇게 커밋을 단위별로 쪼개지 않으면 나중에 더 힘들어지는건 내가 되는 것이다.

profile
프론트엔드 개발자

0개의 댓글

관련 채용 정보