3P by neo 10달전 | favorite | 댓글 1개

나의 가장 좋아하는 Git 커밋

  • Git 커밋 메시지의 중요성을 강조하며, 코드베이스를 문서화하는 데 있어 가장 강력한 도구 중 하나라고 생각함.
  • 개발자 Dan Carley가 작성한 "Convert template to US-ASCII to fix error"라는 커밋을 예로 들어 그 이유를 설명함.
  • GDS(Government Digital Service)에서의 경험을 바탕으로, 공개적으로 코딩하는 것의 이점 중 하나는 조직 외부에서도 이러한 예를 공유할 수 있다는 점임.

이 커밋이 좋은 이유

  • 커밋 메시지와 코드 변경 사항의 비율이 재미있지만, 그것이 공유할 가치가 있다고 생각하는 이유는 아님.
  • 다른 조직이나 개발자였다면 이 커밋 메시지는 단순히 change whitespace 또는 fix bug로 요약될 수 있었을 것임.
  • 대신, Dan은 주변 사람들을 위해 정말 유용한 커밋 메시지를 만드는 데 시간을 할애했음.

변경 사유를 설명함

  • 최고의 커밋 메시지는 변경한 무엇뿐만 아니라 변경했는지를 설명함.
  • 이 커밋에서는 /etc/nginx/router_routes.conf의 내용을 일치시키기 위해 도입된 테스트가 bundle exec rake로 실행될 때 ArgumentError: invalid byte sequence in US-ASCII 오류로 실패한 이유를 자세히 설명함.
  • 이러한 정보는 문서화하기에 매우 가치가 있으며, 사람들이 원래의 맥락을 잊거나 다른 팀으로 옮겨가고 조직을 떠나면서 쉽게 잃어버릴 수 있음.

검색 가능함

  • 커밋 메시지의 첫 부분에는 변경을 유발한 오류 메시지가 있어, 누구든지 코드베이스에서 git log --grep "invalid byte sequence"를 실행하거나 GitHub의 커밋 검색을 사용하여 이 오류를 검색할 수 있음.
  • 실제로 여러 사람들이 이 문제를 검색하고, 이전에 누가 이 문제를 발견했는지, 어떻게 대처했는지를 알아낼 수 있었음.

이야기를 전달함

  • 커밋 메시지는 문제가 어떻게 보였는지, 조사 과정이 어떠했는지, 해결 과정이 어떠했는지에 대한 상세한 내용을 담고 있음.
  • 커밋 메시지는 특정 파일이나 함수, 코드 라인을 문서화하는 것이 아니라, 코드베이스가 겪은 여정에 대한 추가 정보를 문서화하는 데 매우 적합함.

모두를 조금 더 똑똑하게 만듦

  • Dan이 각 단계에서 실행한 명령어를 문서화한 것은 팀 내 지식을 공유하는 가벼운 방법이 될 수 있음.
  • 이 커밋 메시지를 읽음으로써, 누군가는 Unix 도구 세트에 대한 몇 가지 유용한 팁을 배울 수 있음.
  • 이 변경 사항을 검토하는 사람이나 나중에 이 커밋을 찾는 사람 모두 이러한 것들을 배울 수 있음.

연민과 신뢰를 구축함

  • 마지막 단락은 인간적인 맥락을 추가함.
  • 이 말을 읽으면, Dan이 교묘한 버그를 추적하는 데 한 시간을 소비한 것에 대한 좌절감과 해결한 것에 대한 만족감을 느낄 수 있음.
  • 이러한 커밋 메시지는 모든 변경 사항 뒤에 최선의 결정을 내린 인간이 있다는 것을 기억하는 데 도움이 됨.

좋은 커밋의 중요성

  • 이 예는 극단적인 경우이며, 모든 커밋이 이 정도의 세부 사항을 가질 것으로 기대하지는 않음.
  • 그러나 이는 변경 사항 뒤에 있는 맥락을 설명하고, 다른 사람들이 배울 수 있도록 돕고, 코드베이스에 대한 팀의 집단적인 정신 모델에 기여하는 훌륭한 예임.
  • 좋은 커밋 메시지의 이점과 그것을 더 쉽게 구조화하는 데 도움이 되는 도구에 대해 더 알고 싶다면 Joel Chippindale의 "Telling stories through your commits"와 Tekin Süleyman의 "A branch in time"을 추천함.

GN⁺의 의견

  • 이 기사는 Git 커밋 메시지의 중요성을 강조하며, 코드베이스의 역사를 문서화하고 지식을 공유하는 데 있어 커밋 메시지가 얼마나 강력한 도구가 될 수 있는지를 보여줌.
  • Dan Carley의 커밋 메시지는 변경 사유, 검색 가능성, 이야기 전달, 지식 공유, 연민과 신뢰 구축 등 여러 가지 면에서 모범적인 사례를 제시함.
  • 좋은 커밋 메시지 작성의 중요성을 이해하고 실천함으로써, 개발자들은 더 나은 협업과 코드 유지 관리를 경험할 수 있으며, 이는 전체 팀의 생산성과 효율성을 향상시키는 데 기여할 수 있음.
Hacker News 의견
  • GitHub 공동 창립자의 의견:

    • Git 커밋 메시지는 코드 문서화를 위한 독특한 방법이지만 최적화되지 않음.
    • 대부분의 도구는 커밋 메시지의 첫 줄만 보여줌.
    • Git은 이메일 본문처럼 모든 프로젝트 참여자가 읽을 수 있도록 커밋 메시지를 설계했으나, 현실에서는 거의 볼 수 없음.
    • git blame을 사용하여 관련 커밋 메시지를 찾는 것도 어려움.
    • Git 프로젝트의 커밋 메시지는 매우 상세하지만, 실제로는 거의 활용되지 않음.
    • Git을 통한 훌륭한 문서 작성은 대부분의 커뮤니티에서 시간 낭비에 가까움.
  • 특정 문제에 대한 커밋 메시지의 중요성:

    • 문제를 명확하게 설명하는 커밋 메시지의 첫 줄이 중요함.
    • 필요한 경우 추가 정보를 제공하는 나머지 부분을 읽을 수 있음.
  • 커밋 메시지에 대한 개인적인 감정:

    • 훌륭한 커밋 메시지를 작성하는 것에 대한 자부심이 있지만, 다른 사람들에게 가치가 있는지 확신이 없음.
    • 대부분의 사람들은 커밋 메시지를 거의 검색하지 않음.
    • 아름다운 커밋 메시지는 프로그래머의 허영일 수 있으며 실질적인 가치가 없을 수 있음.
  • 커밋 메시지의 첫 줄 작성 전략:

    • git log를 사용할 때 첫 줄이 가장 중요함.
    • 첫 줄에는 무엇을 했는지가 아니라 왜 했는지를 명시해야 함.
    • 뉴스 기사처럼 중요도가 높은 정보부터 상세한 정보까지 순차적으로 작성하는 것이 좋음.
  • 커밋 메시지 수정의 어려움:

    • 커밋 메시지는 작성 후 수정하기 어려움.
    • .md 파일이나 위키, Confluence 등의 문서는 수정이 용이함.
    • 컴포넌트의 설계를 설명하려는 유혹을 피하고, 필요한 경우 문서를 개선하는 것이 좋음.
  • 작은 커밋에 대한 상세한 설명의 중요성:

    • 작은 커밋일수록 상대적으로 긴 설명이 필요할 수 있음.
    • 작은 변경 사항에 대한 이유를 상세히 설명하는 것이 중요함.
  • 커밋 메시지의 한계와 도구의 문제점:

    • 커밋 메시지의 첫 줄을 더 구체적으로 작성할 필요가 있음.
    • 나머지 긴 설명은 큰 가치가 없을 수 있음.
    • 개발 도구의 문제점을 지적하며, 오류 메시지가 더 명확해야 함.
    • 코드 편집 도구가 비표준 공백 문자를 허용하는 이유에 대한 의문 제기.
  • 커밋 메시지보다 커밋 위생의 중요성:

    • 커밋 메시지의 상세함보다는 좋은 커밋 위생이 더 중요함.
    • 깔끔하고 독립적인 커밋은 코드 기능을 쉽게 추출하고 재사용할 수 있게 함.
  • 자동 스쿼시와 리베이스에 대한 비판:

    • 자동 스쿼시는 의미 있는 커밋 메시지 작성을 방해함.
    • 리베이스는 개발자가 의도적으로 정리하기 위한 것이지, 병합 시 기본 패턴이 되어서는 안 됨.