シェア:
){kind=small}
ヨナタンは、C/C++からMatlab、PHP、javascriptまで、アカデミーや業界で素晴らしいプロジェクトに携わってきた。元Webiks社CTO、WalkMe社ソフトウェアアーキテクト。現在はVonageのソフトウェア・アーキテクトであり、eggheadのインストラクターでもある。
従来のコミットを使うべき3つの理由
プログラマとして、あなたはアプリケーション、ライブラリ、マイクロサービス、サービスやライブラリでいっぱいのモノレポ、あるいは（天の邪鬼！）巨大なモノリスを開発するかもしれない。どのようなタイプのアプリケーションを開発するにしても、"正しく "行うのであれば、何らかのバージョン管理を使用することになる(90%はgitを使うでしょう).
問題は、バージョン履歴をどのように管理しているかということだ。バグフィックス、機能追加、ワークスペースでの雑用、あるいは変更をどのように報告するのか？もっと重要なのは、それを見るのがどれだけ簡単かということだ。
従来のコミットは、バージョン管理の標準化されたアプローチで、開発者間の明快さ、一貫性、コラボレーションを強化します。この投稿では、Conventional Commits とは何かを理解し、どのように機能するのかを調べ、Conventional Commits を使うことで得られる 3 つの主なメリットについて説明します。
standard_commit_example
上の図は、一般的なgitコミットの流れを示しています。一本筋が通っているのはいいのですが、多くの疑問が残ります。コミットメッセージから何がわかるのでしょうか?コミットメッセージから何がわかるのでしょうか? fix pathどういう意味なのか？どのパス?どのコンポーネントで？
コミット履歴を見ただけでは答えられない。
機械にもそれはできない。このことは後々のために覚えておいてほしい。
一方、従来のコミット標準に従ったコミットメッセージは以下のようになる：
conventional_commit_example
各コミットの最初の2つの情報を見るだけで、すでに多くのことがわかる。下から順に見ていくと fabコンポーネントに機能が追加されたこと、タイポグラフィの修正が行われたこと、日付ピッカーに機能が追加されたこと、......。 docsに関連する別の機能が追加された。 accordion itemなどなど。
各プッシュの変化について、私たちのコミットがより明確で記述的になったことに同意していただけるでしょうか？
しかし、開発者がコミットメッセージを見るのに多くの時間を費やすことは通常ありませんよね。それでは、Conventional Commitsの本当の実力を見てみましょう。
従来のコミットには、変更履歴の自動生成、自動バージョン管理、チームコミュニケーションの向上という3つの主な利点がある。
従来のコミットに従って変更ログを生成するツールはたくさんある。変更ログは次のようになる：
vivids_auto_generated_changelog
Conventional Commit標準が、通常のコミットを読みやすい変更ログに変換していることにお気づきでしょうか？さらに、新機能やバグの修正を追跡するために、日付でバージョンに分割することもできます。
なぜバージョンがわかるのか？これが次の利点だ。
コンベンショナル・コミット規格は以下のような構造になっている：
{type}({scope}): {description}その タイプは、どのような変更が行われたかを示す。主に3つのタイプがある：機能、修正、雑用。
その スコープは、この変更によって影響を受けるものを指す。これはコンポーネントであったり、ライブラリであったり、アプリであったり、サービスであったりする。
について 説明には、何が変更されたのかをより具体的に記述する。
それが要点だ。詳しいスペックについては 全仕様しかし、私はそれを読むことを勧める。短くて筋が通っている。
では、これがバージョニングにどう役立つのか？
SemVerはソフトウェアのバージョン管理方法です。バージョンは3桁の数字で構成されています： X.Y.Z.
Xはこう呼ばれる MajorYは MinorZは Patch.
ブレークチェンジを行うと、メジャーバージョンが上がる。これは、このスコープのインターフェイスが変更されたことを意味する。
新しい機能を（既存の機能を壊さずに）追加する場合、マイナーバージョンを上げる。
機能なしで、何も壊さずにバグを修正する場合、パッチバージョンを上げる。
何が言いたいかわかるかい？
これで、マシンは我々のコミットを読み、スコープが受け取るべきバージョンを決定することができる。
しかも、自分でやる必要はない。慣習的なコミットは標準的なものなので、自動変更ログ、自動バージョン管理、そして通常はその両方を提供する多くのツールが存在する。
そのようなツールの1つが リリース・プリーズです。 githubアクション.
コミット・メッセージがより読みやすくなることに加え、構造を定義することで別のことが得られる。それはコミットメッセージにコンテキストを与えることだ。たとえその記述が mehであったとしても、コミットのタイプとそのスコープが理解されているため、読者は少なくとも何が起こるかを予想することができます。
この例を見てほしい：
standarized_commits_example
ここに標準化の試みがある。それでも、人間がこれを見ただけでは、どのような変更が行われたのか（これは修正なのか、それとも機能なのか）、またどのコンポーネントに対して行われたのかを理解することはできない。変更履歴もここから推測することはできない。
これを少し変えると次のようになる：
fix(button): verified 48 done and fixed 3 (#172/vivid-103)
feat(button): verified 2 and added demo example (#172/vivid-103)
chore(dialog): fixed 1/5 (font) (#172/vivid-103)説明文が説明的でないので、これはあまり良くない。
でコミットを書かなければならないのであれば、このような記述をする人は少ないだろう。 fix(button): {description}を書かなければならない場合、そのような記述をする可能性は低くなる。を記述する可能性の方が高い。 fixまたは featで行われた button.
いつものことだが、ある程度の基準があることは、人々が物事をより良くするのに役立つ。それは 割れ窓理論.
試してみてください。何が起こるか見てみよう。
VonageのデザインシステムでConventional Commitsを使用しています、 Vivid.
これは 変更ログと リリースログを生成し、リリースバージョンを自動決定するのに役立ちます。
加えて、それ以来、私たちのコミットメッセージはずっと良くなっている。
しかし、従来のコミット強制は、すべてのコミットに対して行われるわけではない。開発中、開発者は好きなだけ好きなコミットを好きなメッセージで追加することができる。
しかし、誰かがプルリクエスト（PR）を作成すると、私たちはプルリクエストのタイトルにConventional Commitを強制します：
github_commit_title_linter
PRのタイトルを確認するために必須なgithubアクションは、従来のコミットに従います。
コミットを JIRA チケットにつなげるための別の標準を追加しました。すべてのPRタイトルは(VIV-XXX)で終わり、XXXは課題番号です。例えば
fix(disabled): adds a consistent cursor to disabled elements (VIV-999)結局、リリースログでは VIV-XXXはJIRAへのリンクに変わる：
convetional_commits_with_jira_links
最終的にPRがマージされると、PRのタイトルがコミットとして設定されます。私たちは squash + mergeブランチからすべてのコミット履歴が削除され mainブランチからすべてのコミット履歴が削除され、従来のコミットだけが残ります。このようになります：
github_squash_and_merge_button
プルリクエストに複数の変更（複数の修正や機能）がある場合、マージコミットのコメントにそれらを追加することができます。このようにします：
pr_with_multiple_commits
従来のコミットツール（ここではrelease-please）は、これらのコメントをメッセージの一部であるかのようにみなします。
こうすることで、コミットメッセージに関して比較的 laxコミットメッセージに関しては、最後のステップで実際に変更を記述するようにする。
従来のコミットには、自動生成される変更履歴と自動バージョン管理という2つのわかりやすい利点がある。
これらの目標を達成する方法はたくさんある。
そのようなツールのひとつが ビーチボール.このツールは、gitの履歴を読む代わりにJSONファイルを生成するCLIを使っている。このツールの大きな利点は、間違いを犯したときに履歴を変更するのがずっと簡単だということです（gitの履歴を変更するのはかなり面倒です...）。
この2つの明確で直接的なメリットのほかに、より良いコミットメッセージを書くことを奨励する効果もあると私は主張する。
間違っているかもしれません。 VonageコミュニティSlackまたは X（旧 Twitter.