Gitでバージョン番号を管理する方法は？
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つのタイプがあります。
- 内部バージョン番号：これは1日に何度もインクリメントできます（たとえば、リビジョン管理番号）
- リリース済みバージョン：これはあまり頻繁に変更されません（例：セマンティックバージョニング）
人々は必要に応じて 異なるスキーム を使用しますが、 セマンティックバージョニング は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のタグを使用して、バージョン番号を追加できます。
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にそのまま使用する方法はありません。