커밋은 언제 해야 할까?

04 Jan 2025

나는 보통 커밋을 할 때 어떠한 기능이 완료되었거나, 중간에 변경 내용을 임시로 저장할 때 커밋을 하곤 한다.

git을 이용해 커밋을 할 때, 어떠한 기준으로 커밋 시점을 정해야 할까? 라는 의문이 생겼고 알아본 결과와 내 생각을 공유하고자 한다.

커밋은 보통 최소 단위로 커밋을 하거나, 의미 있는 단위로 작업을 마쳤을 때 커밋을 해야 한다고 한다.

그래야 나중에 revert하기가 쉬워지고, 커밋 로그를 봤을 때도 어떠한 내용이 반영되었는지 알기가 쉬워진다.

feat, fix, doc, test 와 같이 작업을 분류하고 어떠한 내용을 했는지 한 줄로 표현하기 쉬운 단위로 해야 한다고 한다.

예) [feat: 회원 이메일 체크 서비스 로직 추가]

항상 작은 단위로 커밋을 해야 할까? 큰 단위의 작업이라도 작은 단위로 나누어서 커밋하는 것이 좋다.

큰 작업을 완료하고 커밋 메시지를 작성하게 되면 [fix: User 도메인 로직 수정] 와 같이 뭉뚱그려 작성하게 된다.

이렇게 작성하게 되면, 나중에 확인했을 때 구체적으로 어떤 작업을 했는지 파악하기가 힘들어진다.

또한, 커밋 로그를 봤을 때, 바운더리가 넓은 작업은 같은 커밋 메시지가 여러 번 나올 수 있는 문제가 발생할 수 있다.

예를 들어, [fix: User 도메인 로직 수정]로 작성하게 되면, User 도메인 로직에 닉네임 체크 로직, 회원 이메일 체크 로직 등 모든 User 도메인 로직의 코드를 수정했을 경우 모두 [fix: User 도메인 로직 수정]로 작성하게 된다.

이렇게 되면 pr 로그를 봤을 때 [fix: User 도메인 로직 수정]만 여러 줄 있는 것을 보게 된다.

따라서 큰 작업을 진행 중에도 중간중간 커밋을 하여 아래와 같이 작성하는 것이 좋다.

[fix: User 도메인의 Nickname 중복 확인 로직 수정] [fix: User 도메인의 이메인 형식 확인 로직 수정]

커밋의 제목을 큰 단위로 작성하고 하위 작업을 커밋 메시지 body 부분에 작성하면 되지 않을까?

이 방법도 가능은 하겠지만 지양하는 것이 좋아보인다.

왜냐하면, 커밋 로그가 수십, 수백개가 쌓인 가운데, 어떠한 로직을 구현했는지 커밋을 하나하나 뜯어보는 것은 매우 비효율적이기 때문이다.

body 부분은 최소 단위의 커밋의 추가 상세 설명을 적어 놓는 것이 좋을 것이다.

커밋 메시지는 이렇게 될 것이다.

[fix: User 도메인의 Nickname 중복 확인 로직 수정] 유저 도메인의 닉네임 체크 로직에 ~한 문제가 있어서 ~로 수정을 진행. 해당 로직 수정으로 ~ 클래스에 ~한 부분을 수정 진행.

[fix: User 도메인의 이메일 형식 확인 로직 수정] 유저 도메인의 이메일 체크 로직에 정규 표현식이 잘못되어 있는 부분을 ~의 형식으로 수정 진행.

커밋은 합칠 수는 있지만 분리할 수는 없다. 이 점을 생각하고 틈틈히 커밋을 해주자.