blerp コマンドラインツールが git で管理されていると想像してみましょう。このツールには、 version (たとえば_--version
_)とコミット番号を返す別の_0.1.2
_を返す(隠された)_--commit
_オプションがありますそれが構築された元。
バージョンとコミット番号の両方がコードベースにハードコードされています。
今、私はバグ修正を行い、プログラムをコミットして再構築します。この新しいバージョンは元の0.1.2とは異なりますが、_0.1.2
_は引き続き表示されます。コミットによってのみ、同じ0.1.2ではないことがわかります。そのバグ修正は異なるバージョン番号の価値がありますか?
1つの解決策は、コミットを行うたびに、ハードコードされたバージョン番号を増やすことです(これは、コミットごとに少なくとも2つのファイルを常に変更することを意味します)。これはバインディングソリューションであり、開発者がさまざまなアクティブブランチで作業している場合は機能しません。 Bobがバージョン_0.1.2
_の機能foo
で動作し、Aliceが同じバージョンの機能bar
で動作する場合。彼らはどのようにバージョン番号を増やしますか?ボブは奇数を使用し、アリスは偶数を使用できます。イブが3番目の機能で動作する場合はどうなりますか?
別の解決策は、Gitタグを使用してバージョン番号を自動的に生成することです。スクリプトは、v0.1.2
_などのv
で始まる最も近いタグを検索し、タグ名をバージョン番号に加えて現在のコミットの最初のn桁を使用できます(v0.1.2 (build 4acd21)
)。作業ディレクトリがきれいな場合、これはうまく機能します。ビルド番号の前に_*
_を追加して、作業ディレクトリがクリーンでないことを示すことが想像できます。このソリューションの主な問題は、誰かがソースをエクスポートした場合、blerpをビルドできないことです。
この問題を解決できる代替策は何ですか?
git describe コマンドをご覧ください。このコマンドは、最新のタグと、タグの設定後に行われたコミットの量を表示します。リポジトリの汚れを示すこともできます。
前述のように、このコマンドはgitリポジトリ(.gitフォルダー)およびgitがインストールされていないと機能しません。しかし、今日ではgitがなく、他のすべてのツールがインストールされている、ほとんど想像を絶する開発者です。
アレクセイ・キセレフとダリオはすでに答えにほのめかしましたが、詳細に説明しようと思います。
バージョン管理スキームには2つのタイプがあります。
人々は必要に応じて 異なるスキーム を使用しますが、 セマンティックバージョニング はGitHubの共同設立者であるTom Preston-Wernerによってかなり広く使用され、作成されています。
セマンティックバージョニングはX.Y.Z
のパターンに従います
または、より読みやすい[major].[minor].[patch]-[build/beta/rc]
例えば。 1.2.0-beta
major or X
は、後方互換性のないAPIリリースなど、ソフトウェアに大きな変更がある場合にインクリメントできます。
minor or Y
は、下位互換性のあるAPIが導入されると増分されます。
patch or Z
は、バグ修正後に増加します。
タグを使用して:
Gitのタグを使用して、バージョン番号を追加できます。
git tag -a "v1.5.0-beta" -m "version v1.5.0-beta"
v1.5.0-betaのバージョンタグを現在のGitリポジトリに追加します。この後のすべての新しいコミットは、このタグにコミット番号とコミットハッシュを追加することで自動的に増分されます。これは、git describe
コマンドを使用したビューにすることができます。
v1.5.0-beta-1-g0c4f33f
ここ-1-
はコミット番号、0c4f33f
はコミットのハッシュの略語です。 g
プレフィックスは"git"
を表します。
完全な詳細は、次を使用して表示できます。
git show v1.0.5-beta
あなたが言うように、バージョン管理の問題は通常gitでbranch
とtags
(like semantic versioning pattern)を使用して解決されます。
より良い方法は、git
を使用して、コードベースの変更のみを追跡し、( .gitignore
file)ファイルを構築し、クリーンなリポジトリを維持します。
ビルド結果(pre/compiled files、executables files、distribution files、zips、exe ...)は、環境変数(プラットフォーム、システムArchなど)に依存する可能性があり、レジストリで個別に保持する必要があります。
コードベースが非常に大きく維持が難しい場合は、それを小さなコンポーネントに分割することを検討する必要があります(または git submodule
)開発時の相互依存を回避します。
リビジョン番号は、gitではなく、ユーザーが管理する必要があります。 SVNとは対照的に、コミットごとに増分リビジョン番号が増えることはないため、バージョンをコンテキスト化するためにgitにそのまま使用する方法はありません。