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

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

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

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

可能な解決策：

• Hudsonのビルド番号を使用する（問題：Hudsonを確認して、実際のGitバージョンと関連付ける必要があります）
• 夜間および安定のためにバージョンを手動でアップグレードする（問題：学習曲線、ヒューマンエラー）

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

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

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

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

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

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

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

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

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

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

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

これに非常によく似た分岐構造を使用します。

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

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

例：2.1.0ビルド1337

これは、特定の製品リリースについて、最後に作業したチームを特定でき、必要に応じてリリースに至るまでのすべてのコミットについてgitに問い合わせて問題を診断できることを意味します。

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

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

欲しいものを手に入れる方法の例を示す素敵なブログがあります：

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

Jon Purdyには正しい考えがあります。git flowこれらのブランチの実際の管理も簡単になりgitます。ブランチ管理はに移行するための引数です。

gitあなたがsvn--to- git視点から来ているので、基本的な概要から始めましょう。git以下を考慮してください。

master--...............-.....-..............-
        \             /     /              /
         ---develop---------............../
                            \            /
                             --feature---

上記の、あなたのブランチmasterにdevelop（で示される\）、およびブランチdevelopへfeatureの分岐。ブランチに沿っ/てコミット（-）を使用して、これらのブランチをマージします（）。（コミットはないが、マージが右側にある場合、次がコミットであること.を示すインジケータがあります-）。

簡単です。メインリリースに修正プログラムがある場合はどうなりますか？

master--...............-.....-................-...........-.........-
        \             /     /                / \         /|        /
         \           /     /                /   -hotfix-- V       /
          ---develop---------............../..............-...----
                             \            / \             V   /
                              --feature---   --feature2...----

上記からdevelop分岐しmasterます。で発見されmasterたバグは、から分岐しmaster、修正してからにマージすることで修正されましたmaster。私たちは、その後、合併masterへdevelop、その後developにfeature2から新しいコードを巻かれ、hotfixこれらの枝に。

にfeature2戻るとdevelop、その履歴にはが含まdevelopれますhotfix。同様に、developにマージされてfeature2から、新しいコードでmasterそうマージ、developに戻ってmasterそれはそれは中にコミットに基づいているとして、滞りなく起こるのだろうmasterあなたがから分岐したかのように、時その時masterその時点で。

そのため、これを行う別の方法があります。

master--..........-........-
        \        /\       /
         ---1.0--  --1.1-- 

あなたの1.0のリリースではtagged-取得1.0.1、1.0.2、1.0.3、など。

ここにトリックがあります：1.0でバグを発見し、1.1、1.2、および1.3に影響します。職業はなんですか？

最新または最も古いメンテナンスリリースから分岐して修正します。次に、あなたの新しいマージhotfixに支店を1.3に-そして1.2、1.1と1.0。メンテナンスバージョンの各ブランチから分岐しないでください。にマージ1.0しmasterたり、master戻ってマージしないでください1.0。1つのhotfixブランチを取得し、それをすべてのバージョンブランチにマージします。競合がある場合は、通知されます。コードを確認して、変更が正しいことを確認してgit diffください（友達です）。

特定の変更がどこにでも適用されるようになりました。系統は分岐していますが、大丈夫です。それは偶然ではありません。1.3頭に1.3.17のタグを付け、から分岐している進行中のすべての機能にマージして、先に進み1.3ます。

git flow延長はあなたのためにこれらのメンテナンス、機能、および修正プログラムの支店を管理することができます。ワークフローをいったん終了すると、これは簡単であり、ソースコード管理から多大なトラブルを取り除きます。

私はこれをプログラミングチームで見ましたが、プログラマーとしてそれほど深く働いたことはないので、日々のワークフローを自分で頭を動かしています。

「キーワード」拡張部分のセクション7.2「Git属性」の Pro Gitには、RCSスタイルのキーワードを生成するためのスマッジフィルターを使用した良い例が含まれています。同じ手法を使用して、コードにsome-version-stringを埋め込み、ルールに従ってフォーマットおよび計算します。引き続きスターティングポイントとして使用できgit describeますが、より適切な形式に変換して、v2.5-14-feebdaedから取得することができます。たとえば、clean 2.5.14