Git 커밋 기록은 역사책처럼 읽어야 합니다. 방법은 다음과 같습니다.

Git 커밋 기록은 역사책처럼 읽어야 합니다. 방법은 다음과 같습니다.

 

커밋이 수행한 작업을 해독하는 데 시간을 낭비하지 마세요.

Unsplash의 Thomas Kelley 사진

우리는 역사에서 배울 수 있습니다. 역사는 과거의 어떤 사건이 현재를 형성했는지 알려줍니다. 보스턴 차 사건은 독립 전쟁으로 이어집니다. 워털루 전투는 나폴레옹의 패배로 이어졌다. 어떤 결정과 어떤 커밋이 소프트웨어의 현재 상태로 이어지는지 알 수 있습니까? 아마.

많은 커밋 메시지가 혼란스럽고 지저분하고 쓸모가 없기 때문입니다.

다음과 같은 커밋 메시지를 본(또는 작성한) 것입니다.

wipwork on feature XYZfixed typoFixed JIRA-123

이러한 메시지는 문제를 추적해야 하거나 구현이 있는 이유를 발견해야 하는 경우 도움이 되지 않습니다.

커밋 기록을 개선하려면 두 가지 질문에 답해야 합니다.

1. 무엇이 좋은 커밋 메시지를 만드는가?
2. 동료(및 나)가 이 형식을 따르도록 하려면 어떻게 해야 합니까?

정답은 없습니다. 커밋 메시지에는 변경된 내용과 이유를 확인하기에 충분한 정보가 포함되어야 합니다. 완전한 문장이어야 합니까 아니면 글머리 기호로 충분합니까? 각 커밋 메시지에 티켓 번호가 필요합니까?

제가 드릴 수 있는 최선의 답변은 다음과 같습니다.

동료와 이야기하고 커밋 메시지의 범위에 동의하십시오.

당신은 준비 없이 그 토론에 들어갈 필요가 없습니다. 커밋 메시지의 구조에 대한 제안이 있습니다. 그 중 하나인 기존 커밋을 살펴보겠습니다.

기존 커밋을 커밋 메시지의 프레임워크로 생각하십시오. 사용할 수 있는 구조를 제공합니다. 각 커밋 메시지에는 최소한 유형과 메시지 자체가 포함됩니다. 범위, 본문 및 바닥글은 선택 사항입니다. 커밋에 주요 변경 사항이 포함되어 있음을 표시하는 간단한 방법도 있습니다.

기본 구조는 다음과 같습니다.

[optional !][optional scope]:

[optional body] [optional footer(s)]  

여기 예시들이 있습니다 :

feat: allow user to keep logged infix: messages are now serialized correctlyfeat(api)!: removed the old way users are handledci(deployment): the application will now be deployed on nonlive as well

첫 번째 개선 사항은 즉시 볼 수 있습니다.

이제 각 커밋에는 유형. 버그 수정을 검색하는 경우 다음을 사용하여 모든 커밋을 살펴보십시오. fix. 선택적 범위를 사용하면 검색 범위를 좁힐 수 있습니다.

느낌표는 주요 변경 사항을 나타냅니다. 다음과 같이 커밋 메시지의 바닥글에서 더 명시적일 수도 있습니다.

chore: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.  

유형을 사용하여 의미 체계 버전 번호를 자동으로 생성할 수 있습니다. ㅏ fix 패치 수준을 높이는 반면 feat 마이너 레벨을 높입니다. 각 주요 변경 사항은 주요 수준을 증가시킵니다.

기존 커밋은 커밋 메시지를 개선합니다.

그러나 마음에는 원이로되 육신이 약하도다. 당신의 동료와 당신은 그것을 사용할 수 있지만 빨리 잊어 버릴 수 있습니다. 여전히 지저분한 커밋 메시지로 끝납니다. 간단한 해결책: git이 기존 커밋을 사용하도록 하세요.

git hooks를 사용하여 git의 동작을 변경할 수 있습니다. 서버 측 및 클라이언트 측 후크가 있습니다. 우리 대부분은 자체 git을 호스팅하지 않기 때문에 클라이언트 측 후크에 집중할 것입니다. git hook은 git 워크플로의 이벤트에서 실행되는 셸 스크립트입니다.

하나의 후크가 특히 중요합니다. commit-msg 훅. Git은 커밋 메시지를 입력한 후 이를 실행합니다. 커밋 메시지를 매개 변수로 사용하여 임시 파일의 경로를 가져옵니다. 커밋 메시지가 규칙을 따르는지 확인할 수 있습니다.

예를 들어 이 후크는 커밋 메시지가 10자 이상인지 확인합니다.

간단한 커밋 메시지 후크.

후크를 사용하려면 리포지토리의 루트에 새 디렉터리를 만듭니다. 예를 들면 .githooks 거기에 새 파일을 추가하고, commit-msg . 이름은 git이 그것이 어떤 후크인지 이해하는 데 중요합니다. 파일을 실행 가능하게 만드는 것을 잊지 마십시오!

chmod +x .githooks/commit-msg

이제 git에게 생성된 폴더에서 후크를 찾도록 지시합니다. 각 동료가 한 번씩 수행해야 합니다.

git config core.hooksPath .githooks

Git은 이제부터 짧은 커밋 메시지를 거부합니다.

> git commit -am "abc"
[Commit message] abc
The commit message is to short!

IntelliJ에서도 작동합니다.

커밋 메시지가 짧은 경우 IntelliJ의 오류 메시지입니다.

이제 git hooks를 사용하여 기존 커밋을 적용할 수 있습니다. 유형 뒤에 각 메시지에 티켓 번호 또는 티켓이 없는 경우 NO-JIRA가 포함되어야 하도록 확장했습니다. 이것은 내 후크입니다.

기존 커밋에 대한 commit-msg 후크 + 티켓 번호. (내가 전체 스크립트를 작성한 것은 아닙니다. GitHub에서 찾은 것의 확장입니다. 슬프게도 더 이상 원본을 찾을 수 없습니다.)

저장소에 대한 커밋 메시지가 더 읽기 쉬워졌습니다. 빠른 승리입니다. 저를 믿으십시오. 그러나 가장 중요한 것은 모든 사람이 아이디어에 동의해야 한다는 것입니다. 사람들은 항상 싫어하는 것을 피합니다. 그러니 먼저 동료들과 이야기하십시오.

이것을 충실히 따르지 마십시오. 자신에게 맞는 것을 선택하여 구현하십시오. 시도 해봐!