バージョン管理したい
バージョン管理する方法として、日付ベースの運用と、機能追加ベースの運用があります。 前者をcalver(calendar versioning)と呼び、後者をsemver(semantic versioning)と呼びます。
定期的なサイクルでリリースをするプロジェクトcalver
が適しているのかもしれませんが、
個人用だったり、研究室用だったりするプロジェクトはsemver
でいいのかなと思います。
semver
ではバージョン番号をMajor.Minor.Patch
の3つの数字で表現し、それぞれ次の意味を持っています。
Major
後方互換性のない機能を追加したり、変更を加えた場合に +1
Minor
後方互換性がある機能を追加した場合に +1
Patch
後方互換性があるバグ修正をした場合に +1
これらを自分の頭で考えて、手作業で管理することは(僕にとっては)到底不可能ですが、 コミットメッセージを活用して、サポートしてくれるツールがあります。 僕はPythonで書かれたcommitizenというツールを使っています。 使い方はcommitizenの使い方に整理しました。
注釈
commitizen
には、JavaScriptで書かれたnpmパッケージのcommitizen
もありますが、別物のようです。
コミットメッセージしたい
1コミットの種類(スコープ): 変更点の概要
2
3 長い説明。長い説明。長い説明。長い説明。長い説明。
4 長い説明。長い説明。長い説明。長い説明。長い説明。
5 長い説明。長い説明。長い説明。長い説明。長い説明。
semver
で利用するコミットメッセージは、上記のテンプレートが基本です。
ポイントは、コミットの種類と変更点の概要を必ず書くことです。
とくに、コミットの種類は
fix
、feat
、docs
、style
、refactor
、perf
、test
、build
、ci
のいずれか値を入力します。
スコープは任意ですが、変更を加えたファイル名やクラス名、関数名を書いておくとよいです。
長い説明は省略してOKです。 ただし、複雑な変更を加えた場合は、きちんと説明を書いておくと、未来の自分のためになります。
バージョンアップしたい
コミットメッセージに残したコミットの種類によって、semver
を判断します。
fix
はパッチバージョン+1、
feat
はマイナーバージョン+1、
feat
かつBREAKING CHANGE
の文字列があるとメジャーバージョン+1となります。
その他は、バージョンアップには影響がありません。
ある程度、コミットを貯めた場合には、バージョンアップに関係する一連のコミットの中で、 もっとも大きな変更値が適用されます。