Git 커밋 가이드

• 커밋은 반드시 테스트를 통과한 후 해야한다.

  1. 테스트 중에 발견된 문제가 다 수정된 후에 커밋이 되어야한다는 것
  2. 예를 들어 "이전 커밋 후 테스트에서 발견된 문제 수정" 이라는 별도의 커밋이 있어서는 안된다.

• 커밋은 보통 최소 단위별로 이루어져야한다.

  1. 규모가 큰 리팩토링은 기능 수정과는 별도로 이루어져야한다. (기능 수정과 대규모 리펙토링을 동시에 진행하는 것은 피해야한다.)
  2. 서로 다른 리팩토링 2개를 진행한다면 리펙토링을 각각 커밋해야한다.

• 반드시 너무 작은 단위로 커밋을 하지 않아도 되는 경우도 있다.

  1. 완전히 새로운 기능을 개발하는 중이라면 꼭 모든 기능 별로 커밋을 할 필요는 없다.
  2. 새로운 서비스라면 초기 버전이 나올 때 한번에 커밋을 해도 된다.
  3. 그래도 한번에 커밋된 양이 2000 라인이 넘는다면 코드 리뷰가 굉장히 어려운 일이 된다.
  4. 커밋 히스토리를 보면서 코드 리뷰하는 경우를 고려해서 적당한 단위로 커밋을 하는게 좋다.
  5. 백엔드 코드와 프론트엔드 코드를 반드시 구분해서 커밋할 필요는 없다.

결론적으로 커밋은 세분화되는 것이 좋다

• * 과도하게 세분화된 커밋은 나중에 스쿼시(squash)를 통해서 합칠 수 있지만 그 반대는 불가능하다. 그렇기 때문에 가능하면 작은 단위로 커밋을 하고 나중에 하나로 합치는 방법이 좋다.
• * 테스트를 하다가 문제가 발견되어 수정을 하면 수정 사항은 이전 커밋을 어멘드(amend) 해야 한다. 위에서 얘기한 내용과 같은 얘기지만 별도의 커밋으로 "테스트 이슈 수정"의 커밋을 생성 하는것은 좋지 않다.

• 참고 URL : https://zulip.readthedocs.io/en/latest/contributing/version-control.html