29

現在、バージョン管理には Perforce を使用しています。ビルドを参照するために使用できる厳密に増加する変更番号の便利な機能があります。たとえば、「ビルドが少なくとも 44902 の場合、バグ修正を取得できます」。

分散システム (おそらく git) の使用に切り替えて、ブランチや在宅勤務を容易にしたいと考えています。（どちらもPerforceで完全に可能ですが、gitワークフローにはいくつかの利点があります。）したがって、「トリビュタリ開発」は配布され、共通のリビジョンシーケンスを参照しませんが、すべての変更が行われるマスターgitリポジトリを維持します.ビルドが作成される前にフィードする必要があります。

厳密に増加するビルド ID を保持する最良の方法は何ですか? 私が考えることができる最も簡単な方法は、マスターリポジトリが更新されるたびに起動し、新しいツリーオブジェクト（またはコミットオブジェクト？のハッシュ）を登録する、ある種のポストコミットフックを用意することです。 git) を、ID を配布する集中型データベースと組み合わせて使用​​します。(「データベース」と言いますが、おそらく git タグを使用して、次に利用可能なタグ番号か何かを探すだけです。つまり、「データベース」は実際には .git/refs/tags/build-id/ になります。 )

これは実行可能ですが、これを達成するためのより簡単な、または既に実装されている、または標準/「ベストプラクティス」の方法があるかどうか疑問に思っています。

4

8 に答える 8

30

現在のコミットに対応する単調に増加する数は、

git log --pretty=oneline | wc -l

単一の数値を返します。一意性を追加するために、現在の sha1 をその番号に追加することもできます。

このアプローチはgit describe、タグを追加する必要がなく、マージを自動的に処理するため、 より優れています。

リベースで問題が発生する可能性がありますが、リベースはとにかく「危険な」操作です。

于 2013-02-21T08:42:00.380 に答える
28

私は2番目に使用の提案をしgit describeます。健全なバージョニングポリシーがあり、リポジトリでクレイジーなことを行わない場合、git describe常に単調（少なくとも、リビジョン履歴がツリーではなくDAGである場合は、可能な限り単調）になります。 。

ちょっとしたデモンストレーション：

git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0

の出力はgit describe、次のコンポーネントで構成されています。

  1. 説明を求めているコミットから到達可能な最新のタグ
  2. コミットとタグの間のコミット数（ゼロ以外の場合）
  3. コミットの（省略された）ID（＃2がゼロ以外の場合）

＃2は出力を単調にするものであり、＃3はそれを一意にするものです。コミットがタグの場合、＃2と＃3は省略されるgit describeため、製品リリースにも適しています。

于 2008-09-24T00:35:04.167 に答える
8 
    git rev-list BRANCHNAME --count

これは、よりもはるかにリソース集約的ではありません

    git log --pretty=oneline | wc -l
于 2014-02-27T23:32:03.833 に答える
4

git tag必要なもので十分かもしれません。他の方法では使用しないことに全員が同意するタグ形式を選択します。

注: ローカルでgit pushタグ付けすると、サーバー上のタグは更新されません。そのために使用git push --tagsします。

于 2008-09-23T18:05:00.033 に答える
2

調査する必要がありgit describeます。これは、最新の注釈付きタグ、そのタグ以降のコミット数、およびブランチのヘッドの省略されたコミット ID に関して、現在のブランチ (または渡されたコミット ID) を説明する一意の文字列を提供します。

おそらく、制御されたビルド リリースを実行する単一のブランチがあるとします。この場合、既知のタグ形式で早期コミットにタグを付け、 --match オプションを指定して git describe を使用して、既知のタグに関連する現在の HEAD を記述します。次に、 git describe の結果をそのまま使用するか、本当に単一の数値だけが必要な場合は、正規表現を使用してタグから数値を切り取ることができます。

ブランチを巻き戻さないと仮定すると、次のコミットの数は常にブランチの履歴の一意のポイントを識別します。

例 (bash などを使用)

# make an annotated tag to an early build in the repository:
git tag -a build-origin "$some_old_commitid"

# describe the current HEAD against this tag and pull out a build number
expr "$(git describe --match build-origin)" : 'build-origin-\([0-9]*\)-g'
于 2008-09-23T20:17:41.290 に答える
1

「ラベル」を使用します ビルドが成功した (または失敗した) 場合はいつでもラベルを作成すると、そのビルドを永久に識別することができます。まったく同じではありませんが、分散開発の利点を提供しながら、これらのビルド番号を提供します。

于 2008-09-23T17:37:27.820 に答える
0

Mercurial では、次のコマンドを使用できます。

# get the parents id, the local revision number and the tags
[yjost@myhost:~/my-repo]$ hg id -nibt
03b6399bc32b+ 23716+ default tip

hg を参照してください

于 2009-06-26T12:48:35.387 に答える
0

ご存じのとおり、git は履歴のノードを一意に識別するハッシュ (数値) を計算します。これらを使って、厳密に増やしているわけではありませんが、それで十分だと思われます。(さらに良いことに、それらは常にソースに対応しているため、ハッシュがあれば同じコードになります。) これらは大きな数字ですが、ほとんどの場合、先頭の 6 桁程度で十分です。

例えば、

そのバグは 064f2ea で修正されました...

于 2008-09-24T00:03:18.127 に答える