はじめに フロントエンドエンジニアをしているズッキーです。 アルバイトを含めるとXHTMLの流行りが終わり始めたぐらいの時代から、フロントエンドエンジニアを経験してます。 さて昔と比べると 昨今のクライアント側のマシンスペックの向上や、 ブラウザ機能の発展に伴い、 「フロントエンドに対する、要件や要求」 が年々上がってきているなぁと感じております。 （とても良いこと） 伴い、複数人でフロントエンドを開発するシーンが増えてきました。 最近はフロントエンドエンジニアチームの組織化を色々頑張っているのですが、その中の取り組みの一つである、コミットメッセージの最適化をご紹介させてくださいませ！ 良いコミットメッセージとは 個人的な見解ですが、 なぜ（why）、どこ（where）の何（what）を修正したのかが、 ぱっと読み取れるメッセージだと思ってます。 【良くない例】 「バグ修正」 これだと何を修正したのか、第3者がソースコードを見ないとわからない。。? 【良い例】 「XXXのXXXフィールドの値がない場合に意図しない空白ができるバグを修正」 なぜ（why）、どこ（where）の何（what）が入っていてわかりやすい！☺️ 規約にのっとろう ということで、チームでの開発となると、ルールが必要になりますが、ここでは「Conventional Commits」を紹介します。 Conventional Commits 明示的なコミット履歴を作成するための簡単なルールです。 【公式ドキュメント】 https://www.conventionalcommits.org/ja/v1.0.0/ ※ GitHubのStarは3.6kある（2021年12月24日時点） 概要 下記が公式で紹介されているフォーマットです。 どういう事かわからないと思いますが、詳細は後述するのでまずは共有まで。 【フォーマット】 <型> [任意 スコープ] : <タイトル> [任意 本文] [任意 フッター] 【適用した例】 feat(トップページ): XXXのXXXフィールドの値がない場合に意図しない空白ができるバグを修正 XXXフィールド配列が空で返却された場合に、「〜はございません」のテキストを表示するように修正 Refs: #111 使い方 例を元に、下記の順番で説明します！ 型を指定する 任意でスコープを設定する タイトルを記載する 任意で本文を記載する 任意でフッターを記載する 1. 型を指定する 「どういった作業を行ったのか」を型として指定します。 例でいうとfeatの箇所になります。 下記がよく利用される型の認識です。 型 意味 feat 新しい機能を追加したときに指定 fix バグの修正 BREAKING CHANGE 破壊的な変更 docs ドキュメントのみの変更 style フォーマットの変更（コードの動作に影響しないスペース、フォーマット、セミコロンなど） perf パフォーマンスの改善のための変更 refactor リファクタリングのための変更（機能追加やバグ修正を含まない） test 不足テストの追加や既存テストの修正 2. 任意でスコープを設定する 対象ページや対象コンポーネントなどのスコープを任意で指定します。 例でいうと、(トップページ)の箇所になります。 3. タイトルを記載する コミット内容の概要を簡潔に指定します。 このときに、「なぜ（why）、どこ（where）の何（what）」を意識して書くと良いと思います。 例でいうとXXXのXXXフィールドの値がない場合に意図しない空白ができるバグを修正の箇所になります。 4. 任意で本文を記載する コミット内容の詳細を説明します。 例でいうとXXXフィールド配列が空で返却された場合に、「〜はございません」のテキストを表示するように修正の箇所になります。 5. 任意でフッターを記載する 課題番号（Refs）やレビュワー等（Reviewed-by）を指定します。 例でいうとRefs: #111の箇所となります。 対話形式でコミットメッセージが作れるライブラリ ここでは深く説明しませんが、このようなツールをチームで使う事で、チーム内でのコミットメッセージの統一や、規格を守ってもらうための一助となります。 https://github.com/commitizen/cz-cli 最後に フロントエンドが複雑になってきているが、頼もしい仲間と共同で作業できる時間はすごく楽しいです。 これからも力を合わせて、頑張れるように色々な施策を考えて実行できればと思ってます。 読了いただき誠にありがとうございました！ Developer eXperienceの向上に貢献できていれば、 嬉しく思います。 参考記事

Gitとは Gitとはプログラムソースなどの変更履歴を管理する分散型のバージョン管理システムのことです。プログラムの編集などができ、変更履歴も管理することができます。 Gitで管理しているファイルであれば、編集前のファイルを残したまま、新しく編集したファイルを保存することができます。なので古いバージョンから新しいバージョンまでの管理が簡単です。 エンジニアは多くのコードを編集した上で何か不具合が起きたときに、元のバージョンへ戻すことは多々あります。ですが、ひとつひとつコードの編集の度に古いバージョンの日付や時刻をつけて保存して、また新しい作業をしていては、時間がかかり、人的ミスも増えてしまいます。そういった作業を無駄なく、効率的に行うためのツールがGitです。 GitHubとは GitHubとはGitを利用した開発者を支援するWebサービスです。最初はGitとGitHubの違いが分かりませんでしたが、Gitはツールの名前でGitHubはGitを使ったWebサービスです。 また、GitHubのようなGitのホスティングサービスは他にもGitlabやBacklog、Bitbucketなど複数あります。 Git：誰がいつどのように編集したかを正確に把握できるバージョン管理システムのこと。 Github: Gitの仕組みと連携して、他のユーザーとやりとりしやすくしているWEBサービスの名称。 Gitは上記の通り、CUI仕様（操作するのにキーボードでの入力が必要）なので、不慣れな方にとっては使いにくいです。一方でGithubはGUI仕様（マウスだけで操作できるもの）なので、画面上でマウスを使って操作できたり、複数のユーザーでコミュニケーションをとりやすいように機能が整備されています。このような点がGithubが活用されている要因の一つでしょう。 Git用語について Git構造 repository（リポジトリ） ファイルやディレクトリの状態を記録する場所、貯蔵庫 local repository（ローカルリポジトリ） 自分のパソコンの中に作られるリポジトリ remote repository（リモートリポジトリ） 自分以外の他のコンピュータの中にあるリポジトリ。ネットワーク上に存在し、複数人でも管理ができるリポジトリ(GitHubなど) fork（フォーク） 他の人のリモートリポジトリを自分のリモートリポジトリに複製 clone（クローン） リモートリポジトリの内容を自分のローカル環境(自分のPC上)にコピー init（イニット） リポジトリを新規作成 pull（プル） リモートリポジトリの内容をローカルリポジトリに取り込む branch（ブランチ） 作業履歴を枝分かれさせて記録する ひとつのプロジェクトから枝分かれをさせ、別の作業を行うことを「ブランチを切る」という master branch（マスターブランチ） プロジェクトの本流のブランチ merge（マージ） 修正変更を加えたブランチを元のブランチに統合 reset（リセット） コミットした内容を取り消す revert（リバート） 指定したコミットを削除した内容のコミットを作成 rebase（リベース） 作業が完了したブランチを分岐(masterなど)のブランチにくっつける ※rebase -iで過去のコミットをまとめたり編集もできる cherry-pick（チェリーピック） 特定のコミットだけをピックアップして取り込む（複数可） stash（スタッシュ） 作業中の変更を一時的に退避させる conflict（コンフリクト） 同じファイルの同じ場所の変更が同時に起こった時 check out（チェックアウト） ブランチの切り替え fetch（フェッチ） リモートリポジトリの最新データを取得 push（プッシュ） ローカルリポジトリの修正内容をリモートリポジトリに反映 pull request（プルリクエスト） 自分がした変更をリポジトリに取り込んでもらうよう要求