web-dev-qa-db-ja.com

Gitで数値バージョン管理スキームをどのように実現しますか？

私の組織では、SVNからGitへの移行を検討しています。移動に反対する議論の1つは次のとおりです。

バージョン管理はどのように行うのですか？

NetBeansプラットフォームに基づくSDKディストリビューションがあります。 SVNリビジョンは単純な番号なので、プラグインとSDKビルドのバージョン番号を拡張するために使用できます。 Gitへの移行時にこれをどのように処理しますか？

可能な解決策：

  • Hudsonのビルド番号を使用する（問題：Hudsonをチェックして、それを実際のGitバージョンに関連付ける必要がある）
  • 毎晩安定したバージョンを手動で更新する（問題：学習曲線、ヒューマンエラー）

他の誰かが同様の問題に遭遇してそれを解決した場合、私たちはその方法を聞きたいです。

version-controlgitsvnbuildsversioning
135
Erlend

tags を使用して、バージョン番号でコミットをマークします。

git tag -a v2.5 -m 'Version 2.5'

タグを上流にプッシュ-これはデフォルトでは行われません。

git Push --tags

次に describe コマンドを使用します。

git describe --tags --long

これにより、次の形式の文字列が得られます。

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag
163
Jon Purdy

これはいくつかのプロジェクトで浮かび上がってきました。これまでのところ、最善の解決策は、次のようなバージョン番号を生成することです。

x.y. <コミット数> .r <git-hash>

通常、これはビルドシステムによって生成され、いくつかの静的ファイルまたはタグの組み合わせを使用してメジャーリビジョン番号、git rev-list HEAD | wc -l（git logを使用するよりも高速）、およびgit rev-parse HEADを取得します。その理由は次のとおりです。

  1. 高レベルのバージョン管理を明示的に実行する機能が必要でした（つまり、x.y）
  2. 並行開発が行われているときは、同じバージョン番号を生成する必要はありませんでした。
  3. バージョンがどこから来たかを簡単に追跡したかったのです。
  4. 平行線がマージされたとき、我々は新しいバージョンがどちらのブランチよりも高く解決することを望んだ。

番号2はほとんどの人には見えませんが、really重要であり、分散ソース管理ではreallyは困難です。 SVNは、単一のリビジョン番号を提供することでこれを支援します。魔法のように＃4も解決しながら、コミットカウントは可能な限り近いことがわかります。ブランチが存在する場合、これはまだ一意ではありません。その場合、ハッシュを追加して、＃3もきれいに解決します。

これのほとんどは、Pythonのpipによるデプロイに対応するためのものでした。これは、並列開発中にpip installが少し奇妙になる可能性があることを保証しました（つまり、異なるブランチの人々からのパッケージが混在しますが、確定的な方法で）、マージ後、すべてが整理されます。公開されたリベースまたは修正の存在を除けば、これは上記の要件に対して非常にうまく機能しました。

ご参考までに、Pythonパッケージはバージョン番号の文字を処理する方法（つまりaeは0未満であり、 "1.3.10.a1234" <"1.3.10" <"1.3.10.1234"）を作成します。

46
Jayson

これは少々やり過ぎかもしれませんが、方法をお知らせします。

this によく似た分岐構造を使用します。

Hudsonは「開発」ブランチを構築し、0から始まるビルド番号を増分します。ビルド番号は各プロジェクトに固有であり、バージョン管理でタグ付けされます。これは、たとえば、どの開発ブランチビルド42の開発元であるかを正確に把握できるようにするためです（各プロジェクトは、プロジェクトのさまざまな側面で作業する複数のチームを持つことができるため、各プロジェクトは複数の開発ブランチを並行して持つことができます）。

特定のビルドがリリースするのに十分であると判断すると、そのビルドをトリガーしたコミットにリリースバージョン番号のタグが付けられます。これはマーケティングによって決定されます。つまり、開発チームは最終的なバージョン番号が何であるかを気にせず、マーケティングは、適切と思われるバージョン番号を自由に並べ替えることができます。最終バージョン番号とビルド番号はどちらもリリースされた製品に含まれています。

例：2.1.0ビルド1337

つまり、特定の製品リリースについて、どのチームが最後に作業したかを知ることができ、必要に応じて、リリースに至るまでのすべてのコミットについてgitにクエリを発行し、問題を診断できます。

10
Carl

バージョンは、チェックイン時に保存されたディレクトリツリー内のすべてのファイルのSHA1ハッシュをハッシュして識別されます。このハッシュは、完全な履歴を読み取ることができるように、親チェックインのハッシュと一緒に保存されます。

GIT-VERSION-GENを介して 'git-describe'を使用するプロセスと、リリースにタグを付けるときにビルドプロセスを介してこれを追加する方法を見てください。

ここにあなたが望むものを得る方法の例を与える素晴らしいブログがあります：

http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/

8
SoftwareCarpenter