동료가 좋아할 Git Commit 메시지 작성
우리는 모두 거기에 있었습니다. "Git이 혼란스럽습니다.", "왜 그냥 메인 브랜치로 푸시할 수 없나요?", "아무도 이 메시지를 읽지 않을 것입니다."이러한 생각은 정상이며 Git을 배운 대부분의 사람들은 아마 공감할 것입니다. 몇 년 동안 사용되어 온 코드 기반으로 작업하기 전에는 좋은 커밋 메시지에 감사하지 않을 수 있습니다. 또는 이전 프로젝트로 돌아갈 때.
이 기사에서는 여러분과 동료들이 좋아할 Git 커밋 메시지를 작성하는 방법을 보여드리겠습니다.
Git 커밋 메시지가 중요한 이유
이전 프로젝트를 열고
git log
로 커밋 메시지를 확인했습니까? 그렇지 않다면 지금 그렇게 하는 것이 좋습니다. "스타일 수정"또는 "끝점 추가"로 채워지지 않은 경우 훌륭합니다! 당신이 우리와 같다면 계속 읽어보세요 😄또는 몇 년 동안 사용된 코드 기반을 가진 회사에 입사했을 수도 있습니다. 그리고 일부 코드가 추가된 이유를 이해하려고 합니다. 당신이 그것을 바꾸면 무엇이든 깨뜨릴 것입니까? 이 경우 좋은 커밋 메시지는 매우 중요합니다.
간단히 말해서 좋은 Git 커밋 메시지를 작성함으로써 자신과 동료의 미래를 대비할 수 있습니다. 그리고 개발자로서 우리는 코드를 작성하는 것보다 읽는 것이 훨씬 더 많습니다.
코드 읽기와 쓰기
Uncle Bob(Robert C. Martin - Clean Code와 같은 유명한 프로그래밍 서적의 저자)은 말합니다.
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” (ref.)
때로는 코드를 이해하기 위해 커밋 메시지도 읽어야 합니다. 좋은 커밋 메시지를 작성하는 노력이 그만한 가치가 있다는 것을 이제 알았으면 합니다!
좋은 Git 커밋 메시지를 작성하는 방법
이제 커밋 메시지가 중요하다는 것을 확신했으므로 동료들이 좋아할 방식으로 메시지를 작성할 수 있는 방법을 살펴보겠습니다!
커밋 메시지는 제목과 본문의 두 부분으로 구성됩니다. 다음은 bitcoin 저장소의 예입니다.
commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <[email protected]>
Date: Fri Aug 1 22:57:55 2014 +0200
Simplify serialize.h's exception handling
Remove the 'state' and 'exceptmask' from serialize.h's stream
implementations, as well as related methods.
...
첫 번째 줄은 제목이고 줄 바꿈 다음은 본문입니다.
이유에 집중
이것이 가장 중요한 규칙입니다. 그리고 가장 흔한 실수이기도 합니다. 커밋 메시지는 추가된 내용이 아니라 코드가 추가된 이유를 설명해야 합니다. 코드를 읽을 수 있는 것을 보기 위해. 하지만 그 이유를 이해하려면 추측만 할 수 밖에 없습니다.
내가 코드 작성자일지라도 결국 이유를 잊게 될 것입니다.
제목 줄에 명령형 분위기 사용
명령형 기분은 "행동이 수행되도록 요구하거나 요구하는 데 사용되는"을 의미합니다. 이것은 Git이 기본적으로 사용하는 분위기이며, 당신도 그래야 합니다.
예를 들어
git revert
명령은 소위 "커밋 되돌리기"를 생성합니다. 이 커밋에는 "'스키마에 필드 추가' 되돌리기"라는 명령형 분위기의 제목이 있습니다.시스템/앱/등에 알리고 있다고 생각할 수 있습니다. 어떻게 행동할지. 처음에는 어색할 수 있지만 익숙해질 것입니다.
Note: You can write in whatever mood you prefer for commit bodies.
제목 줄 길이를 50자로 제한
GitHub에서
...
로 끝나는 커밋 메시지를 본 적이 있습니까? GitHub는 제목이 72자를 넘으면 잘리기 때문입니다. 나머지 제목 줄은 커밋 본문으로 이동합니다.50자는 GitHub의 권장 사항입니다. 커밋을 더 읽기 쉽게 만들기 위한 제한이 있습니다. 그리고 코드 변경 사항을 간결하고 이해하기 쉬운 방식으로 설명해야 합니다.
코드 변경 사항을 50자로 설명하는 데 문제가 있는 경우 한 번에 너무 많은 변경 사항을 커밋한 것일 수 있습니다. 이 경우 커밋을 여러 커밋으로 분할해야 합니다.
결론
Git 커밋 메시지를 작성할 때 따라야 할 가장 중요한 세 가지 규칙입니다. 이러한 규칙을 따르면 동료는 커밋이 무엇인지 빠르게 이해할 것입니다.
요약하자면:
git commit 모범 사례에 대해 자세히 알아보려면 this excellent blog post을 확인하십시오.
, 또는 GitHub에서 나와 연결
Reference
이 문제에 관하여(동료가 좋아할 Git Commit 메시지 작성), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/simeg/write-git-commit-messages-that-your-colleagues-will-love-1757텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)