そこで、Git GUI を使用してリポジトリを作成しています。しかし、Google、ドキュメント、または「リビジョン式」とは何かの痕跡を見つけることができず、新しいブランチを作成する必要があります。
また、これはプログラムの他の多くの場所で使用されているようですので、知っておくことは重要だと思います.
私は StackOverflow でこれに関する質問を見つけましたが、その男は答えを得ませんでした。
知っておく必要があるのは、リビジョン式とは何ですか?
git は、多くの一般的な操作中にコミットを識別できる必要があります
https://git-scm.com/docs/git-rev-parse
コミットを識別する方法はいくつかあります。ブランチ、タグ、コミット sha1、または式を使用できます。例えば:
git log HEAD
HEAD
最終的に特定のコミットに解決され、そのログが提供されます。次のように言うこともできます。
git log master
master
はブランチであり、これも特定のコミットに解決されます。
git log fd72e9c99312
これが実際のコミットです。
以下のドキュメントは、あなたが探しているものです。http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.htmlgit-rev-parse
のコマンド ドキュメントから引用。
リビジョンの指定
リビジョン パラメータは通常、コミット オブジェクトの名前を指定しますが、必ずしもそうである必要はありません。それらは、拡張 SHA1 構文と呼ばれるものを使用します。オブジェクト名を綴るさまざまな方法を次に示します。このリストの最後近くにリストされているものは、コミットに含まれるツリーとブロブに名前を付けるためのものです。
完全な SHA1 オブジェクト名 (40 バイトの 16 進文字列)、またはリポジトリ内で一意のその部分文字列。たとえば、オブジェクト名が dae86e で始まるオブジェクトがリポジトリに他にない場合、dae86e1950b1277e545cee180551750029cfe735 と dae86e は両方とも同じコミット オブジェクトに名前を付けます。
git-describe からの出力。つまり、最も近いタグの後に、オプションでダッシュとコミット数が続き、その後にダッシュ、ag、および省略されたオブジェクト名が続きます。
シンボリック参照名。たとえば、master は通常、$GIT_DIR/refs/heads/master によって参照されるコミット オブジェクトを意味します。たまたま heads/master と tags/master の両方がある場合は、heads/master と明示的に言って、どちらを意味するかを git に伝えることができます。あいまいな場合、次のルールで最初に一致したものを取得することで、a のあいまいさが解消されます。
$GIT_DIR/ が存在する場合、それが意味します (これは通常、HEAD、FETCH_HEAD、ORIG_HEAD、および MERGE_HEAD にのみ役立ちます);
それ以外の場合は $GIT_DIR/refs/ が存在する場合。
それ以外の場合は $GIT_DIR/refs/tags/ が存在する場合。
それ以外の場合は $GIT_DIR/refs/heads/ が存在する場合。
それ以外の場合、 $GIT_DIR/refs/remotes/ が存在する場合。
それ以外の場合は、$GIT_DIR/refs/remotes//HEAD (存在する場合)。
HEAD は、作業ツリーでの変更が基づいているコミットに名前を付けます。FETCH_HEAD は、最後の git-fetch 呼び出しでリモート リポジトリからフェッチしたブランチを記録します。ORIG_HEAD は、HEAD を大幅に移動するコマンドによって作成され、操作前の HEAD の位置を記録するため、ブランチの先端を実行前の状態に簡単に戻すことができます。MERGE_HEAD は、git-merge の実行時にブランチにマージするコミットを記録します。
ref の後にサフィックス @ が続き、日付指定が中かっこのペアで囲まれている (例: {yesterday}、{1 月 2 週間 3 日 1 時間 1 秒前} または {1979-02-26 18:30:00})以前の時点での参照の値を指定します。このサフィックスは、ref 名の直後にのみ使用でき、ref には既存のログ ($GIT_DIR/logs/) が必要です。これは、特定の時点でのローカル参照の状態を検索することに注意してください。たとえば、先週ローカルの master ブランチにあったもの。特定の時間に行われたコミットを確認したい場合は、--since と --until を参照してください。
その参照の n 番目の前の値を指定するために、中かっこのペア ({1}、{15} など) で囲まれた序数指定を伴うサフィックス @ が後に続く参照。たとえば、master@{1} は master の直前の値であり、master@{5} は master の 5 番目の値です。このサフィックスは、ref 名の直後にのみ使用でき、ref には既存のログ ($GIT_DIR/logs/) が必要です。
ref 部分が空の @ コンストラクトを使用して、現在のブランチの reflog を取得できます。たとえば、ブランチ blabla にいる場合、@{1} は blabla@{1} と同じ意味になります。
特別な構文 @{-} は、現在のブランチの前にチェックアウトされた th 番目のブランチを意味します。
リビジョン パラメータのサフィックス ^ は、そのコミット オブジェクトの最初の親を意味します。^ は 番目の親を意味します (つまり、rev^ は rev^1 と同等です)。特別なルールとして、rev^0 はコミット自体を意味し、rev がコミット オブジェクトを参照するタグ オブジェクトのオブジェクト名である場合に使用されます。
リビジョン パラメータの接尾辞 ~ は、最初の親のみに続く、名前付きコミット オブジェクトの第 2 世代の祖父母であるコミット オブジェクトを意味します。つまり、rev~3 は rev^^^ と同等で、rev^1^1^1 と同等です。このフォームの使用例については、以下を参照してください。
接尾辞 ^ の後に中括弧で囲まれたオブジェクト タイプ名が続く (例: v0.99.8^{commit}) は、オブジェクトがタグである可能性があり、そのタイプのオブジェクトが見つかるか、オブジェクトを逆参照できなくなるまで、タグを再帰的に逆参照することを意味します。もう (この場合は barf)。先ほど紹介した rev^0 は rev^{commit} の略です。
サフィックス ^ の後に空の中かっこのペアが続く (例: v0.99.8^{}) は、オブジェクトがタグである可能性があり、非タグ オブジェクトが見つかるまでタグを再帰的に逆参照することを意味します。
コロン、スラッシュ、テキストの順: これは、指定されたテキストで始まるコミット メッセージを持つコミットを指定します。この名前は、任意の参照から到達可能な最も若い一致するコミットを返します。コミット メッセージが ! で始まる場合は、それを繰り返す必要があります。特殊なシーケンス :/! の後に ! 以外の何かが続く は現在予約されています。
サフィックス : の後にパスが続きます。これは、コロンの前の部分によって名前が付けられたツリーっぽいオブジェクトの指定されたパスにあるブロブまたはツリーに名前を付けます。
オプションでステージ番号 (0 から 3) が続くコロンと、パスが続くコロン。これは、指定されたパスのインデックスにある blob オブジェクトに名前を付けます。ステージ番号 (およびそれに続くコロン) が欠落している場合は、ステージ 0 エントリに名前が付けられます。マージ中、ステージ 1 は共通の祖先、ステージ 2 はターゲット ブランチのバージョン (通常は現在のブランチ)、ステージ 3 はマージされるブランチのバージョンです。
これは、Jon Loeliger によるイラストです。コミット ノード B と C は両方ともコミット ノード A の親です。親コミットは左から右に並べられます。
G H I J
\ / \ /
D E F
\ | / \
\ | / |
\|/ |
B C
\ /
\ /
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2 = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
gahooa は包括的な答えを提供します。一般的なケース:
master
)gitk
。git log
git の素晴らしい世界へようこそ。TMIはコースに匹敵します...
Another case, when using Emacs: Just type Ctrl-x v l
to list all revisions. For a newbie to git (but not to Emacs/CVS) I was surprised to see that revisions are listed as:
commit 8d5ab12cd76d5e6098e5894c8713ec605fd9f153
It's definitely a refreshing change from the Major.minor.bugfix.build
notation.
What's more (pleasantly) surprising is that Emacs handles git automatically without any need for me to tell it (via .emacs) that it needs to refer to git instead of CVS. Pretty amazing.
So to summarize, when Emacs prompts for a revision, just enter that 40 hex-digit number.