개발자가 6 개월 전에 작업 한 무언가를 찾기 위해 시간을 되돌아 갔을 때, 많은 경우 그가 그 특정 헌신을 왜 했는지 이해하지 못했으며, 그 유일한 이유는 그가 헌신 메시지를 작성하는 올바른 방법을 따르지 않았기 때문입니다. 전 세계적으로 개발자가 연습하는 헌신 메시지 표준이 있으며 대중적인 표준을 따르는 것이 좋기 때문에 좋은 시간 후에 돌아오거나 다른 사람이 헌신 메시지를보고있을 때 그들은 헌신 메시지처럼 보이지 않을 것입니다! 변화의 맥락을 다른 개발자들에게 알리는 가장 효과적인 기술은 잘 작성된 Git 커미트 메시지입니다. 변화의 맥락을 다른 개발자들에게 알리는 가장 효과적인 기술은 잘 작성된 Git 커미트 메시지입니다. 팀은 먼저 그들이 구축하고 있는 제품의 버전 제어 기록을 지정하는 혜택 메시지 협약에 대해 결정해야 합니다.Teams should first decide on a commit message convention that specifies the version control history of the product they are building. 훌륭한 Git commit 메시지는 적절한 스타일, 콘텐츠 및 메타데이터가 있어야 합니다. 잘 알려진 Git commit는 이 협약을 따릅니다: <type>(<scope>): <message> 그것은 다음 중 하나가 될 수 있습니다 : <type> 새로운 캐릭터를 위한 피드백 생산 코드를 재현하기 위한 refactor, 예를 들면, 기능을 재명하기 위한 refactor. 문서에 대한 변경에 대한 docs. 사용자를 위한 버그 수정 성능 향상을 위한 PERF 형식 변경을 위한 스타일, 실패한 반색자 등 실패한 테스트를 추가하기 위한 테스트, refactoring tests. build 구성, 개발 도구 또는 사용자에게 관련이없는 다른 변경 사항을 업데이트하기 위해 build를 구축합니다. 또한 팀이 따르는 표준에 따라 사용자 정의 타입도 추가할 수 있습니다.이 표준은 ESLint 팀이 따릅니다. . 여기에 범위는 선택 사항이며 메시지 부분에는 단일 라인 문구(72자 이상)가 포함되어야 하며, 커미트가 무엇을 의미하는지 요약할 수 있습니다. 많은 개발자들은 또한 메시지를 주제 라인으로 사용하고 몸을 추가합니다; 그것은 기본적으로 헌신의 설명이지만, 하나의 라인 헌신 메시지는 당신이 맥락을 이해할 수있는 한 선호됩니다 (헌신 무엇이며 왜).If the commit requires a more detailed description that cannot be explained in a single line, a commit body is always necessary. 당신은 또한 같은 도구를 사용할 수 있습니다 또는 당신의 Commit 메시지를 표준화합니다. 글라이트 위원 이것뿐만 아니라, 당신은 또한 당신의 위임 메시지를 확인하고 지침을 따르지 않는 경우 오류를 나타내는 도구가 있는지 궁금해 할 수 있습니다. 그것은 당신의 팀이 헌신 협정을 준수하는 데 도움이됩니다.It helps your team adhere to a commit convention. 링크 링크 종종 업계 전문가들은 JIRA 또는 Click Up 티켓을 의무 메시지로 사용하여 모든 것이 언제든지 연결되거나 추적 될 수 있으며 코드베이스는 미래의 개발자를 위해 유지할 수 있습니다. 일부 팀은 또한 자신의 commit 메시지에 emojis를 추가하는 것을 좋아합니다.I have curated a list of emojis and their respective meanings.You can check it out . 여기에 마지막으로, 중요한 것은 귀하의 의무 메시지가 의미가 있어야하며 특정 변경 사항이 무엇인지에 대해 동료 개발자 또는 미래 개발자를 혼란시키지 않는다는 것입니다. 전통적인 헌신, 의미적 헌신 또는 업계가 따르는 관행에 대해 더 알고 싶다면, 여기에 당신을위한 몇 가지 리소스가 있습니다. 전통적인 위원회 Semantic Commit CBeams에서 commit 메시지를 작성하는 방법
