다음의 포스트를 참고하여 작성하였습니다.
깃(Git) 커밋 가이드, (2022.01.27)


이전에 Git Commit Message Convention 관련하여 다뤄본 적이 있다. 요즘 회사에서 Github(Git)를 제대로 사용하게 되면서 드는 몇가지 생각이 있었다.


커밋은 어떤 단위로 해야할까?

Git을 사용하다보면 각자 사용하는 방법이 조금씩 다르다는 것을 느끼게 된다.

나는 그 중 커밋을 언제마다 해야할까에 대해서 고민을 많이 하게 된다. 참고 포스트에서 아래와 같은 문구를 읽게 되었다.

“커밋은 논리적으로 구분이 되고, 일관성이 유지되는 단위로 최대한 작게 쪼개서 되어야합니다.

(Each commit is a minimal coherent idea)”.

사실 최대한 작게 Commit을 하게되면 일거리가 많이 늘어나게 되어 귀찮아진다. 그래도 이렇게 운영할 경우 코드리뷰를 위해서 볼 때나 버그나 사이드 이펙트를 발견하는 데 큰 도움이 된다. 특히 히스토리를 통해 현재 코드가 어떤 과정을 거쳐 변하게 되었는지도 이해할 수 있습니다.


커밋은 꼭 논리적으로 구분되며 일관성 있어야한다.

  • 커밋은 무조건 테스트 통과 후 진행한다.
  • 각 커밋은 운영 서버에 반영되어도 안전해야 한다. 피치 못할 사정으로 안전하지 않은 커밋을 하게되는 경우에는 그 사유를 꼭 자세히 작성해야한다.

커밋은 보통 최소 단위별로 되어야한다.

  • 기능 수정과 리펙토링을 동시에 진행하는 것은 피해야한다.
  • 코드를 원래 있던 파일에서 다른 파일로 옮기는 것은 별도의 커밋으로 진행되어야합니다.

기능을 수정하는 것과 동시에 하거나 해당 파일의 리펙토링과 같이 하는 것도 피해야합니다.

  • 2개의 다른 리펙토링을 진행했다면 각 리펙토링을 각각 커밋해야합니다.
  • 2개의 다른 기능은 나누어 각각 커밋을 해야합니다.
  • 커밋을 하려고 메시지를 작성하고 있는데 몇개의 다른 분류의 내용을 나열하고 있다면 아마도 그 나열된 각각의 내용으로 구분해서 커밋을 해야하는 신호일 것이다.

즉 커밋 메세지에 ”&“라는 문구가 들어가지 않도록 해야한다.


  • 너무 쪼개진 커밋은 squash를 통해 추후에 합칠 수 있지만, 반대는 불가능하다. 최대한 쪼개는 것이 좋다.
  • 테스트를 하다가 문제가 발견되어 수정을 하는 경우 이전 커밋을 amend하는 것이 좋다. 버그 수정을 별도의 커밋으로 “테스트 이슈 수정”의 코멘트로 생성하는 것은 좋지 못하다.