개발 생산성을 높이는 원자적 커밋(Atomic commit)

개발 생산성을 높이는 원자적 커밋(Atomic commit)

 

좋은 아티클이 있어서 기록해두고자 글을 작성한다. 첫 번째는 원글이며, 아래는 그 글을 소개하는 한글로 된 블로그 글이다. 한글 정리는 아래 블로그에 잘 되어있다. 

 

 

1. How atomic Git commits dramatically increased my productivity - and will incrase yours too

How atomic Git commits dramatically increased my productivity - and will increase yours too

 

2. 개발 생산성을 높이는 원자적 커밋(Atomic commit)

개발 생산성을 높이는 원자적 커밋 (Atomic Commit)

 

원글 필자는 많은 사람들이 좋은 개발 방법들을 알고 있지만 실제로 하지 않는 것으로 서론을 시작한다. 그리고 원자적 커밋이 무엇인지, 왜 원자적 커밋을 해야 하는지 설명한다. 

나는 이 아티클에서 가장 강조하는 부분을 단순함이라고 이해했다. 요구사항은 늘 변화하고 때로는 명확하지 않을 때도 있다. 그럴 수록 일단 시작하기보단 최대한 면밀히 검토하고 단순화한 다음 시작하자는 어찌보면 당연한 이야기인데, 필자의 말처럼 당연한 건 알겠고, 행하고 있는가? 과연 나는 이상 지향적으로 일하고 있는가? 생각해 볼 필요가 있다. 현실에서는 일하면서 누구나 하던대로, 또 기계적으로 일하기 쉬운 부분이기도 하다. 그 기능을 나눌 수 있는 데까지 나누어야 결국 원자적일 수 있는데, 그 고민까지가 어렵다. 

아티클을 보면서 생각한 것인데 작업은 commit amend를 활용하면 롤백도 쉬울 수는 있을 것 같고, 혹은 commit은 실제 내 작업 단위로 하되 실제 원격저장소에 push 할 때 squash 하는 기능들을 이용할 수도 있을 것 같다. 

 

다만, 결국 개발도 협업인지라 내가 작업한 코드 위에 여러 코드들이 결국 합쳐지고, 또 여러 충돌 상황들이 생길 텐데 이 경우는 결국 롤백하기에는 매우 어려운 상황이 된다. 비즈니스적으로 봤을 때 내 코드가 고쳐졌다는 건 버그가 있었거나, 개선할 부분들이 있었다는 의미가 되는데 이 경우는 어떻게 하면 좋을지 고민해볼 여지가 있다. 버그 수정이나 개선도 사실 원래의 commit에 포함되었어야 할 수도 있다. git을 사용한다면, rebase 할 수도 있겠지만 이후의 코드들에 문제가 생길 여지가 많아서 더 위험할 수도 있다. 사실 이런 부분들은 이 기사가 이야기하는 원자적 커밋으로 인해 발생되는 문제가 아니며 오히려 기사대로 일을 "잘" 했다면 오히려 발생 가능성이 줄어들 수 있을 것이라 생각한다. 다만 이런 케이스들은 어떻게 대처할 수 있을까? 결국엔 좋은 테스트 이야기가 나올 것 같다.

 

옆길로 새는 것은 이쯤 하고, 평소 작업 단위로 커밋하고자 노력했었지만 실제로 그러했는지, 내 일하는 습관은 어땠는지, 어떤 부분들이 부족했고, 아쉬웠는지 회고해보면 좋을 것 같다.