cvs 나 subversion(이하 svn) 등 버전 컨트롤 프로그램을 사용하면서
소스 코드 변경 사항을 적당히 조절해서 커밋할 필요가 있다는 것을 느낀다.

특히 svn 에서는 로그가 체인지 셋(change set)단위로 남으므로
의미있는 변경 사항 별로 따로 커밋 하는 것이
나중에 다른 개발자들이 변경 사항을 익히는(follow up) 데도 도움이 되고
버그 추적할 때에도 중요한 역할을 한다.

그러나 때로는 엄청나게 많은 변경 사항에 대해서 얼마 단위로 어떻게 나눠서 커밋 할 지 고민 될 때도 있다.
물론 이런 고민 없이 그냥 한꺼번에 커밋하는 경우도 있는데,
이런 경우 미처 확인 하지 못한 코드 실수가 그대로 반영될 가능성이 높아진다.
보통 올바른 커밋 습관은 커밋 직전에 변경 사항을 diff 해 보는 것이다.

당연히 의미 있고 서로 연관 있는 체인지 셋내에서는 논리적으로 코드의 흐름을 파악하기 쉽다.
따라서 만약 마지막 체크 타임에 논리적 오류를 조금이라도 더 발견할 가능성이 높다.
또한 원래 버그라는 것이 시간적으로 개발 시점과 가까운 시일일수록 쉽게 잡을 수 있기 때문에
이와 같은 마지막 확인 작업은 매우 매우 매우 중요하다.

하지만 변경 사항이 많아지고 여러 가지 기능에 대한 변경/개선 등이 섞여 있으면
최후의 기회를 놓칠 가능성이 매우 높아진다.
우선은 변경된 부분이 많으므로 마지막 확인 작업 자체를 생략할 가능성이 높고
둘째로 집중해서 코드를 논리적으로 해석할 수 있는 가능성도 줄어든다.

결국 코드 수정도 계획적으로 할 필요가 있다.
아니면 소스 커밋이라도 적당한 단위로 나누어서 예쁘게 해야한다.
적당한...이라는 말이 사실은 제일 어렵기도 하지만 -_-;;