グッドコミットメッセージの書き方:実用的なGitガイド

有用な改訂履歴を作成するには、チームは最初に使用するコミットメッセージ規則に同意する必要があります。これは個人的なプロジェクトにも当てはまります。

最近Hashnodeで、職場ではどのコミットメッセージ規則を使用していますか?」と尋ねました。そして、私は、ユーザーが職場や個人的なプロジェクトで使用する規則を説明するという驚くべき反応を得ました。

職場ではどのコミットメッセージ規則を使用していますか?

@hashnodeから//t.co/HewCBxRCbr

—BOLAJI✨(@iambolajiayo)2019年11月25日

この記事では、適切なコミットメッセージを作成する方法と、その理由について説明します。

PS:この記事は私のブログで最初に公開されました。

Gitによるバージョン管理の概要

バージョン管理ソフトウェアは、現代のソフトウェア開発者の慣行の重要な部分です。

これまでのところ、Gitは世界で最も広く使用されているバージョン管理システムです。これは、Linuxオペレーティングシステムカーネルの有名な作成者であるLinus Torvaldsによって2005年に開発された、分散型で積極的に保守されているオープンソースプロジェクトです。

Gitは初めてですか?公式のスタートガイドまたは私が行った過去の講演からのこのスライドをチェックしてください。

コミットメッセージとは何ですか?

コミットコマンドはGitリポジトリにステージングした後、ローカルリポジトリへの変更を保存するために使用されます。ただし、Gitに変更を保存する前に、大量の編集を行った可能性があるため、保存する変更をGitに指示する必要があります。これを行うための優れた方法は、変更を識別するためのコミットメッセージを追加することです

コミットオプション

  • -m

このオプションは、コミットのメッセージを設定します。

git add static/admin/config.yml git commit -m "Setup multiple roles for netlify-cms git gateway" 
  • -aまたは--all

このオプションは、追跡、変更、または削除されたすべての(新しいファイルを含む)ファイルを自動的にコミットします。

git commit -a -m "Add a new role for netlify-cms git gateway" 
  • -修正

このオプションは、現在ステージングされている変更または新しいコミットメッセージで最後のコミットを書き換えます。これは、まだリモートリポジトリにプッシュされていないコミットでのみ実行する必要があります。

git add . git commit --amend -m "Update roles for netlify-cms git gateway" 

なぜあなたは良いコミットメッセージを書くべきですか?

「これは単なる個人的なプロジェクトです」と言うかもしれません。はい、今は一人で働いていますが、チームで働いたり、オープンソースに貢献したりするとどうなりますか?

巧妙に作成されたGitコミットメッセージは、変更に関するコンテキストを、そのプロジェクトに取り組んでいる他の開発者に、そして実際にあなたの将来の自分に伝えるための最良の方法です。

git log古いプロジェクトの1つを実行して、開始以来使用してきた「奇妙な」コミットメッセージを確認したことがありますか。過去にいくつかの変更を加えた理由を理解するのは難しい場合があります。この記事を早く読んでください:)。

コミットメッセージは、変更が行われた理由を適切に伝え、開発とコラボレーションをより効率的にすることを理解できます。

Gitでコミットメッセージを書く方法

今まではgit commit -m "Fix X to allow Y to use Z"、個人的なプロジェクトでのみ、主題だけを使用し、追加の説明はありませんでした。これはgit commit -m "Fix typo in README.md、のような小さくて明確な修正には最適ですが、より大規模な変更の場合は、いくつかの詳細を追加する必要があります。

エディター方式

git commitメッセージやオプションなしで実行すると、デフォルトのテキストエディタが開き、コミットメッセージを書き込むことができます。

「デフォルト」エディタを設定するには:

git config --global core.editor nano 

これにより、デフォルトのエディターとしてnanoを使用するようにGitが構成されます。「nano」を「emacs」、「vim」、または好みに応じて置き換えます。

開いたエディターでは、最初の行が件名(簡単な説明)で、その後に空白行を残し、それ以外はすべて拡張説明(本文)です。

コマンドライン方式

git commit -m "Subject" -m "Description..." 

最初の-mオプションは件名(簡単な説明)で、次のオプションは拡張説明(本文)です。

良いコミットメッセージを書く方法

さまざまなチームや開発者が適切なコミットメッセージを作成するために使用する規則がいくつかあります。コミットメッセージを作成するための一般的なルールとヒントの概要のみを説明します。従う規則を決定する必要があります。そして、あなたが会社で働いているか、オープンソースに貢献しているなら、あなたは彼らの慣習に適応しなければなりません:)。

一貫性を保つために、仕事に1つの規則を使用し、個人的なプロジェクトに別の規則を使用できます。これは、いつか転職する可能性があり、規則も変更される可能性があるためです。

このスレッドでいくつかのすばらしいコミットメッセージの規則を確認するか、誰かが決定を下すのを助けるためにあなたの規則を追加してください。

これは、もともとティム・ポープによって書かれた良いコミットメッセージの素晴らしいテンプレートです

Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here - Use a hanging indent If you use an issue tracker, add a reference(s) to them at the bottom, like so: Resolves: #123 

見栄えがいいですよね?これがあなたもあなたを素晴らしいものにする方法です:

  1. コミットのタイプを指定します。
  • feat:特定のアプリケーションに追加する新機能
  • fix: A bug fix
  • style: Feature and updates related to styling
  • refactor: Refactoring a specific section of the codebase
  • test: Everything related to testing
  • docs: Everything related to documentation
  • chore: Regular code maintenance.[ You can also use emojis to represent commit types]
  1. Separate the subject from the body with a blank line
  2. Your commit message should not contain any whitespace errors
  3. Remove unnecessary punctuation marks
  4. Do not end the subject line with a period
  5. Capitalize the subject line and each paragraph
  6. Use the imperative mood in the subject line
  7. Use the body to explain what changes you have made and why you made them.
  8. Do not assume the reviewer understands what the original problem was, ensure you add it.
  9. Do not think your code is self-explanatory
  10. Follow the commit convention defined by your team

Conclusion

The most important part of a commit message is that it should be clear and meaningful. In the long run, writing good commit messages shows how much of a collaborator you are. The benefits of writing good commit messages are not only limited to your team, but indeed expand to yourself and future contributors.

Want to learn more about Git and become a professional "version controller"? Check out these excellent resources:

  • //try.github.io/
  • //git-scm.com/book/en/v2
  • //www.git-tower.com/learn/
  • //learngitbranching.js.org/
  • //github.com/commitizen/cz-cli