모든 커밋이 "완벽"했으면 했다.
commit history는 아주아주 중요하다고 생각한다. 굳이 버전 관리의 관점이 아니더라도, 프로그램을 이해하는데에 "역사"란 매우 중요한 자원이다. 그래서 "불필요한", "더러운" 커밋은 하기 싫었다.
각각의 커밋이 "완전"하기를 바랐다. 물론, 프로그램의 특성 상 언제든 버그가 있을 수 있고, 개발 중이기에 미완성인 프로그램이지만, 커밋 하나하나는 최대한 무결하기를 바랐다. 그래서 client-side git hook을 사용했다. commit하기 전에 반드시 린팅과 포메팅을 하도록, 모든 테스트에 통과하도록. 어느 커밋으로든 reset 했을 때, 미구현된 기능을 제하면 배포될 코드와 다름없이 깨끗한 코드가 있었으면 했다.
그런 이유에서 CI Pipeline을 remote에 조성하는게 매우 싫었다. 물론, 프로그램 실행 환경의 통일을 생각하면 remote가 옳다. 하지만, server-side hook으로는 개별 commit에 대한 강제가 불가능하지 않은가? 혹자는 git merge --squash를 말할지 모르지만, 난 모든 기록은 유지되어야 한다고 생각한다. (git merge --no--ff를 강제해야한다고 생각한다.)
"모든 커밋을 무결하게", 말은 좋은 말이다. 하지만 결국 커밋을 하기가 너무 어렵고 망설여졌다.
"One change, One commit"
기능을 하나 변경하면, 커밋을 하나 하라고 한다. 듣기 좋은 만큼이나 이해도 쉽다. 하지만 적용은 너무 어려웠다.
지금껏 도전했던 일들은, "개발"에 목적이 있기 보단 "공부"에 목적이 있었다. 때문에 기능 개발을 서두르지도 않았고, 요구사항은 자주 변경됐다. 마찬가지로 사용하는 lib나 framework 이해도가 부족했고 프로그램 구조가 자주 변경됐다. 커밋 히스토리를 보면 한 기능에 대한 수정이 매우 자주 반복된다. 우선 작성하고, 구조를 가다듬고, 구조를 변경하고, 다시 가다듬고, 다른 기능을 만들다가, 구조를 변경하고, 다시 작성하고, 다시 가다듬고. 기록은 지져분해 졌다. 그래서 어느순간부터는 One change가 아니라 "대충 이 정도 하면 더 이상 수정이 없지 않을까?" 싶을 때, 그동안의 변경사항을 한 번에 커밋하곤 했다.
commit history는 수정 가능하다.
좋은 커밋을 생각하면서 커밋을 어렵게 만드는건 본말전도가 아니었을까? 통합 branch에 병합되기 전이면 조금 더러워도 괜찮지 않을까? git은 다양한 옵션을 제공한다. 간단하게 git commit --amend를 사용해도 될 일이고, git rebase -i로 히스토리를 직접 수정해도 될 일이다.
결론, 조금 더 가벼운 마음으로
여전히 포메팅 정도는 강제할 생각이지만, 커밋이 완벽하기를 바라는건 그만두려고 한다. "Start Small"이라고 배웠다. 뭐든 처음부터 완벽하길 바라는건 너무 바보같은 생각이니까.
