仕事では SVN を使用していますが、個人的なプロジェクトでは Git を使用することにしました。それで、昨日 Git をインストールしましたが、Git に相当するリビジョン番号は何だろうと思います。
バージョン 3.0.8 に取り組んでおり、すべてのバグ修正には、このバグ修正について話すときに使用できる独自のリビジョン番号があるとします。では、Git のコードに 3.0.8 のタグを付けると、リビジョン番号やその他のより詳細な種類の識別として何を使用できるでしょうか? ハッシュは人間にとってあまりユーザーフレンドリーではないことがわかりました。
最新の Git (私の場合は 1.8.3.4) を使用し、ブランチを使用しない場合は、次のことができます。
$ git rev-list --count HEAD
68
しかし、これにはあらゆる種類の問題があり、必要に応じて簡単に再現できなかったり、コミット ハッシュに簡単に戻すことができない場合があります。したがって、それを避けるか、ヒントとしてのみ使用してください。
良いニュースでも悪いニュースでも、ハッシュはリビジョン番号です。SVNからgitに切り替えたときも、これに問題がありました。
git で「タグ付け」を使用して、特定のリビジョンを特定のバージョンの「リリース」としてタグ付けすると、そのリビジョンを簡単に参照できます。このブログ投稿をチェックしてください。
理解しておくべき重要なことは、git はリビジョン番号を持つことができないということです。分散型の性質について考えてみてください。ユーザー A と B の両方が自分のローカル リポジトリにコミットしている場合、git はどのように合理的に連続したリビジョン番号を割り当てることができるでしょうか? A は、互いの変更をプッシュ/プルする前に B を認識していません。
もう 1 つ注目すべき点は、バグ修正ブランチの単純化されたブランチです。
リリースから始めます: 3.0.8。次に、そのリリースの後、次のようにします。
git branch bugfixes308
これにより、バグ修正用のブランチが作成されます。ブランチをチェックアウトします。
git checkout bugfixes308
ここで、必要なバグ修正の変更を行います。
git commit -a
それらをコミットし、マスター ブランチに切り替えます。
git checkout master
次に、他のブランチからこれらの変更を取り込みます。
git merge bugfixes308
そうすれば、別のリリース固有のバグ修正ブランチができますが、バグ修正の変更は引き続きメインの開発トランクにプルされます。
このgit describeコマンドは、特定のコミットを参照する、もう少し読みやすい名前を作成します。たとえば、ドキュメントから：
git.git 現在のツリーのようなものを使用すると、次のようになります。
[torvalds@g5 git]$ git describe parent v1.0.4-14-g2414721つまり、私の「親」ブランチの現在のヘッドは v1.0.4 に基づいていますが、その上にいくつかのコミットがあるため、describe は追加のコミット数 (「14」) とコミットの省略されたオブジェクト名を追加しました。自体 ("2414721") を最後に付けます。
特定のリリースに適切な名前を付けたタグを使用している限り、これは SVN の「リビジョン番号」とほぼ同等であると見なすことができます。
他のポスターは正しく、「リビジョン番号」はありません。
「リリース」にタグを使用するのが最善の方法だと思います。
しかし、私は以下を使用してリビジョン番号を偽装しました (クライアントがリビジョンと進行状況を確認するためだけに、Subversion で使用するのと同じように git からのリビジョンの増加を望んでいたため)。
これを使用して「HEAD」の「現在のリビジョン」がシミュレートされていることを示します。
git rev-list HEAD | wc -l
しかし、クライアントが「リビジョン」 1302 にバグがあると私に言ったらどうしますか?
このために、~/.gitconfig の [alias] セクションに以下を追加しました。
show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'
usinggit show-rev-number 1302は、「リビジョン」のハッシュを出力します:)
しばらく前に、その「テクニック」についてのブログ投稿 (ドイツ語)を作成しました。
Git does not have the same concept of revision numbers as subversion. Instead each given snapshot made with a commit is tagged by a SHA1 checksum. Why? There are several problems with a running revno in a distributed version control system:
First, since development is not linear at all, the attachment of a number is rather hard as a problem to solve in a way which will satisfy your need as a programmer. Trying to fix this by adding a number might quickly become problematic when the number does not behave as you expect.
Second, revision numbers may be generated on different machines. This makes synchronization of numbers much harder - especially since connectivity is one-way; you may not even have access to all machines that has the repository.
Third, in git, somewhat pioneered by the now defunct OpenCM system, the identity of a commit (what the commit is) is equivalent to its name (the SHA id). This naming = identity concept is very strong. When you sit with a commit name in hand it also identifies the commit in an unforgeable way. This in turn lets you check all of your commits back to the first initial one for corruption with the git fsck command.
Now, since we have a DAG (Directed Acyclic Graph) of revisions and these constitute the current tree, we need some tools to solve your problem: How do we discriminate different versions. First, you can omit part of the hash if a given prefix, 1516bd say, uniquely identifies your commit. But this is also rather contrived. Instead, the trick is to use tags and or branches. A tag or branch is akin to a "yellow stick it note" you attach to a given commit SHA1-id. Tags are, in essence, meant to be non-moving whereas a branch will move when new commits are made to its HEAD. There are ways to refer to a commit around a tag or branch, see the man page of git-rev-parse.
Usually, if you need to work on a specific piece of code, that piece is undergoing changes and should as such be a branch with a saying topic name. Creating lots of branches (20-30 per programmer is not unheard of, with some 4-5 published for others to work on) is the trick for effective git. Every piece of work should start as its own branch and then be merged in when it is tested. Unpublished branches can be rewritten entirely and this part of destroying history is a force of git.
When the change is accepted into master it somewhat freezes and becomes archeology. At that point, you can tag it, but more often a reference to the particular commit is made in a bug tracker or issue tracker via the sha1 sum. Tags tend to be reserved for version bumps and branch points for maintenance branches (for old versions).
興味がある場合は、バージョン番号を git infos hereの形式で自動的に管理しました
<major>.<minor>.<patch>-b<build>
ここで、build はコミットの総数です。に興味深いコードが表示されますMakefile。バージョン番号の別の部分にアクセスするための関連部分は次のとおりです。
LAST_TAG_COMMIT = $(shell git rev-list --tags --max-count=1)
LAST_TAG = $(shell git describe --tags $(LAST_TAG_COMMIT) )
TAG_PREFIX = "latex-tutorial-v"
VERSION = $(shell head VERSION)
# OR try to guess directly from the last git tag
#VERSION = $(shell git describe --tags $(LAST_TAG_COMMIT) | sed "s/^$(TAG_PREFIX)//")
MAJOR = $(shell echo $(VERSION) | sed "s/^\([0-9]*\).*/\1/")
MINOR = $(shell echo $(VERSION) | sed "s/[0-9]*\.\([0-9]*\).*/\1/")
PATCH = $(shell echo $(VERSION) | sed "s/[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/")
# total number of commits
BUILD = $(shell git log --oneline | wc -l | sed -e "s/[ \t]*//g")
#REVISION = $(shell git rev-list $(LAST_TAG).. --count)
#ROOTDIR = $(shell git rev-parse --show-toplevel)
NEXT_MAJOR_VERSION = $(shell expr $(MAJOR) + 1).0.0-b$(BUILD)
NEXT_MINOR_VERSION = $(MAJOR).$(shell expr $(MINOR) + 1).0-b$(BUILD)
NEXT_PATCH_VERSION = $(MAJOR).$(MINOR).$(shell expr $(PATCH) + 1)-b$(BUILD)
Bash 関数:
git_rev ()
{
d=`date +%Y%m%d`
c=`git rev-list --full-history --all --abbrev-commit | wc -l | sed -e 's/^ *//'`
h=`git rev-list --full-history --all --abbrev-commit | head -1`
echo ${c}:${h}:${d}
}
のようなものを出力します
$ git_rev
2:0f8e14e:20130220
あれは
commit_count:last_abbrev_commit:date_YYmmdd
コミットのSHA1 ハッシュは、Subversion のリビジョン番号に相当します。
これは、他のソリューションに基づいてメイクファイルで行ったことです。これにより、コードにリビジョン番号が付与されるだけでなく、リリースを再作成できるハッシュも追加されることに注意してください。
# Set the source control revision similar to subversion to use in 'c'
# files as a define.
# You must build in the master branch otherwise the build branch will
# be prepended to the revision and/or "dirty" appended. This is to
# clearly ID developer builds.
REPO_REVISION_:=$(shell git rev-list HEAD --count)
BUILD_BRANCH:=$(shell git rev-parse --abbrev-ref HEAD)
BUILD_REV_ID:=$(shell git rev-parse HEAD)
BUILD_REV_ID_SHORT:=$(shell git describe --long --tags --dirty --always)
ifeq ($(BUILD_BRANCH), master)
REPO_REVISION:=$(REPO_REVISION_)_g$(BUILD_REV_ID_SHORT)
else
REPO_REVISION:=$(BUILD_BRANCH)_$(REPO_REVISION_)_r$(BUILD_REV_ID_SHORT)
endif
export REPO_REVISION
export BUILD_BRANCH
export BUILD_REV_ID
ビルド番号として git ハッシュを使用する際の問題は、それが単調に増加しないことです。OSGi は、ビルド番号にタイムスタンプを使用することを提案しています。ブランチへのコミット数は、subversion または perforce の変更番号の代わりに使用できるようです。
各コミットには一意のハッシュがあります。それ以外には、git にリビジョン番号はありません。より使いやすくしたい場合は、自分でコミットにタグを付ける必要があります。
Antビルド プロセスを使用している場合は、次のターゲットを使用して git でプロジェクトのバージョン番号を生成できます。
<target name="generate-version">
<exec executable="git" outputproperty="version.revisions">
<arg value="log"/>
<arg value="--oneline"/>
</exec>
<resourcecount property="version.revision" count="0" when="eq">
<tokens>
<concat>
<filterchain>
<tokenfilter>
<stringtokenizer delims="\r" />
</tokenfilter>
</filterchain>
<propertyresource name="version.revisions" />
</concat>
</tokens>
</resourcecount>
<echo>Revision : ${version.revision}</echo>
<exec executable="git" outputproperty="version.hash">
<arg value="rev-parse"/>
<arg value="--short"/>
<arg value="HEAD"/>
</exec>
<echo>Hash : ${version.hash}</echo>
<exec executable="git" outputproperty="version.branch">
<arg value="rev-parse"/>
<arg value="--abbrev-ref"/>
<arg value="HEAD"/>
</exec>
<echo>Branch : ${version.branch}</echo>
<exec executable="git" outputproperty="version.diff">
<arg value="diff"/>
</exec>
<condition property="version.dirty" value="" else="-dirty">
<equals arg1="${version.diff}" arg2=""/>
</condition>
<tstamp>
<format property="version.date" pattern="yyyy-mm-dd.HH:mm:ss" locale="en,US"/>
</tstamp>
<echo>Date : ${version.date}</echo>
<property name="version" value="${version.revision}.${version.hash}.${version.branch}${version.dirty}.${version.date}" />
<echo>Version : ${version}</echo>
<echo file="version.properties" append="false">version = ${version}</echo>
</target>
結果は次のようになります。
generate-version:
[echo] Generate version
[echo] Revision : 47
[echo] Hash : 2af0b99
[echo] Branch : master
[echo] Date : 2015-04-20.15:04:03
[echo] Version : 47.2af0b99.master-dirty.2015-04-20.15:04:03
バージョン番号を生成するときにファイルがコミットされていない場合は、ダーティ フラグがここにあります。通常、アプリケーションをビルド/パッケージ化するときは、すべてのコード変更をリポジトリに含める必要があるためです。
Git マニュアルによると、タグはこの問題に対する優れた回答です。
Git で注釈付きタグを作成するのは簡単です。最も簡単な方法は、tag コマンドを実行するときに -a を指定することです。
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v0.1
v1.3
v1.4
2.6 Git の基本 - タグ付けを確認してください
コミットのSHA-1 IDとともに、サーバー時間の日付と時刻が役に立ちましたか?
このようなもの：
コミットが 2013 年 8 月 19 日の 11:30:25 に発生すると、6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025 と表示されます。
Visual Studio のポスト ビルド イベント
echo >RevisionNumber.cs static class Git { public static int RevisionNumber =
git >>RevisionNumber.cs rev-list --count HEAD
echo >>RevisionNumber.cs ; }