【Git】ログを見やすくしよう

Git のログを見返したとき、経緯や意図が調べやすくなっていると
設計を変更する検討がスムーズに進められます。
経緯や意図を踏まえずに設計を変えると、
元の設計が持っていた機能をなくしてしまう可能性があるためです。

Linux 知識の要らない Git 講座 目次にもどる

ストーリー

ビジネスオーナーの A さんと Web ディレクターの B さんは
お店のホームページに Google Maps を追加して、背景画像を変更しました。

ふたりは更にホームページ経由の来客を増やそうと、
ホームページに表示されるコンテンツの順番をどのようにするのが最適なのか
相談をしていました。
「この Google Maps はなんで付けたんだっけ？」

タグを付けよう

Git では、コミットにタグをつけておくことができます。
このタグはブランチと異なり、チェックアウトしてコミットしても
もとのコミットから動くことはありません。

この機能をどのように利用するかは Git を使うチーム次第ですが、
多くの場合、制作物を公開した時点のコミットに
日付・時刻やバージョン番号をタグとして登録するように利用されています。
このようにしておくと、公開されたコミットがひと目でわかり、
公開時点の日付・時刻やバージョン番号も簡単に調べることができます。

手順

1. タグを追加したいコミットを右クリック → [このバージョンでタグを作成]

2. [名前] → [タグ] を入力して [OK] ボタンをクリック

ここではタグ名は日付・時刻で入力しています。

するとログにタグが表示されます。

この状態では、まだローカルリポジトリーにタグを作っただけで、
他の Git ユーザーとタグを共有できていません。
続いてタグをプッシュします。

3. タグを右クリック → [プッシュ]

4. プッシュ対象がタグになっていることを確認して [OK] ボタンをクリック

[Ref] → [ローカル] が “refs/tags/(タグ名)” になっていることを確認してから
プッシュします。

「成功」と表示されたら処理が正常に完了しています。

GitHub を見てみると、 [release] の数字が “0” から “1” に変わっています。

クリックすると、リポジトリーに追加したタグの一覧が表示され、
タグを追加したコミット時点の制作物を
ダウンロードすることができるようになっています。

このリンクからダウンロードする制作物には Git リポジトリーは含まれません。

Git では、タグはリリース (公開) の用途に限定された機能ではありませんが、
2019/11/13 現在の GitHubの仕様では、
タグはリリース (公開) の用途として扱われます。
参考: Tag without release – GitHub Community Forum

コミットメッセージに理由を書こう

例えば、次の 2 種類のコミットメッセージを比べると、
後者の方が、後から経緯や意図を確認しやすくなります。

Google Maps の追加、背景画像の変更

Google Maps の追加、背景画像の変更

- Google Maps の追加: 場所の問い合わせ削減のため
- 背景画像の変更: IT 業界へのアピールのため

GitHub の Issues のような課題追跡システムを使っている場合は
経緯や意図の詳細を課題追跡システムに記載し、
その課題の ID をコミットメッセージに書いたりすることでも
同様の効果が得られるでしょう。

The seven rules of a great Git commit message

コミットメッセージにどのような内容を残すかの取り決めも
Git を使うチーム次第ですが、ここでは一例として
“The seven rules of a great Git commit message” という取り決めを
紹介します。
How to Write a Git Commit Message

この取り決めは英語を前提としているので、
日本語でコミットメッセージを書くときなどは
すべての取り決めをそのまま当てはめられないこともありますが、
知っておくと自分たちの取り決めを考える参考になるでしょう。

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

これらを翻訳すると以下のような内容になります。

1. 件名と本文を空白行で区切りましょう

理由

• Git が最初の空白行までをコミットの件名として扱うように
  設計されているため

2. 件名を 50 文字に制限しましょう

理由

• Git の公式ドキュメントが 50文字以内を推奨しているため
• コミットの内容を 50 文字に要約できないとき、
  内容を複数に分割してコミットすることを検討する機会になるため

参考: Developer Tip: Keep Your Commits “Atomic” – Fresh Consulting

3. 件名を大文字始まりにしましょう

理由

• Git がマージなどのときに自動生成するコミットのメッセージが
  そのようになっており、表記を統一して見やすくするため

4. 件名をピリオドで終えないようにしましょう

理由

• 50 文字を有効に使うため

5. 件名に命令形を使いましょう

理由

• Git がマージなどのときに自動生成するコミットのメッセージが
  そのようになっており、表記を統一して見やすくするため
• コミットを命令や指示のように扱うことで、
  コミットを適用したときに何が起こるかを理解しやすくするため

6. 本文を 72 文字以内で改行しましょう

理由

• Git はコミットメッセージを自動的に折り返して表示しないため
• 72 文字の根拠は記載がありませんが、
  Linux の修正プログラム作成時の規約に由来するようです

参考: Git Commit Messages : 50/72 Formatting – Stack Overflow

7. 「どのように」でなく「なに」「なぜ」を説明するために本文を使いましょう

理由

• 「どのように」は、差分を見れば理解できるため
• 「なに」「なぜ」は差分を見ただけではわからないことがあり、
  後から調べるのに多くの時間が必要になるため

Linux 知識の要らない Git 講座 目次にもどる