gitでタグとブランチを使用する方法を理解するのに少し苦労しています。
コードの現在のバージョンをcvsからgitに移動しました。次に、特定の機能のためにそのコードのサブセットに取り組んでいます。他の数人の開発者もこれに取り組んでいますが、私たちのグループのすべての開発者がこの機能に関心があるわけではありません。ブランチまたはタグを作成する必要がありますか?どのような状況で一方を他方に対して使用する必要がありますか?
理論的な観点から:
技術的な観点から:
refs/tags/
は名前空間に存在し、タグオブジェクト(注釈付きおよびオプションでGPG署名付きタグ)を指すか、オブジェクトを直接コミットする(ローカル名にあまり使用されない軽量タグ)か、ごくまれにツリーオブジェクトまたはblobオブジェクト(GPG署名など)を指すことができます)。refs/heads/
のみを指すことができます。ポインターは、ブランチ(シンボリック参照)またはコミット(デタッチされたHEADまたは名前のないブランチ)を直接参照する必要があります。HEAD
refs/remotes/<remote>/
、リモートリポジトリの通常のブランチに従います<remote>
。gitglossaryのマンページも参照してください。
ブランチ
「ブランチ」は活発な開発ラインです。ブランチでの最新のコミットは、そのブランチのチップと呼ばれます。ブランチの先端はブランチヘッドによって参照されます。ブランチヘッドは、ブランチで追加の開発が行われるときに前進します。単一のgitリポジトリは任意の数のブランチを追跡できますが、作業ツリーはそのうちの1つ(「現在の」または「チェックアウトされた」ブランチ)に関連付けられ、HEADはそのブランチを指します。
鬼ごっこ
タグまたはコミットオブジェクトを指すref。ヘッドとは対照的に、タグはコミットによって変更されません。タグ(タグオブジェクトではない)はに格納され
$GIT_DIR/refs/tags/
ます。[...]。タグは、最も一般的に、コミットの祖先チェーンの特定のポイントをマークするために使用されます。タグオブジェクト
別のオブジェクトを指すrefを含むオブジェクト。これには、commitオブジェクトと同じようにメッセージを含めることができます。(PGP)署名を含めることもできます。その場合、「署名付きタグオブジェクト」と呼ばれます。
タグは、ある時点での特定のブランチのバージョンを表します。ブランチは、同じコードベースで他の開発作業と同時に実行される可能性のある別の開発スレッドを表します。ブランチへの変更は、最終的には別のブランチにマージされて統合される可能性があります。
通常、特定のバージョンにタグを付けて、それを再作成できるようにします。たとえば、これはXYZCorpに出荷されたバージョンです。ブランチ_は、コードの開発を継続しながら、特定のバージョンのコードに継続的な更新を提供するための戦略です。提供されたバージョンのブランチを作成し、メインラインで開発を続行しますが、提供されたバージョンを表すブランチにバグ修正を行います。最終的には、これらのバグ修正をメインラインにマージします。多くの場合、分岐とタグ付けの両方を一緒に使用します。メインラインとそのブランチの両方に適用できるさまざまなタグがあり、配信、バグ診断などのために、再作成する可能性のある各ブランチに沿って特定のバージョン(たとえば顧客に配信されるもの)をマークします。
実際にはこれよりも複雑です-またはあなたが作りたいほど複雑です-しかし、これらの例はあなたに違いのアイデアを与えるはずです。
リポジトリをプロジェクトの進捗状況を記録した本と考えると...
ブランチは、これらの粘着性のあるブックマークの1つと考えることができます。
まったく新しいリポジトリには、そのうちの1つ(と呼ばれる)しかありません。これは、作成master
した最新のページ(commitと考えてください)に自動的に移動します。ただし、本の他の関心のあるポイントをマークするために、より多くのブックマークを自由に作成して使用できるため、すぐにブックマークに戻ることができます。
また、特定のブックマークを本の他のページにいつでも移動できます(git-reset
たとえば、を使用)。関心のあるポイントは通常、時間の経過とともに変化します。
タグは章の見出しと考えることができます。
タイトル(注釈付きタグを考えてください)が含まれる場合と含まれない場合があります。タグは、本の歴史的な関心のポイントをマークするという点で、ブランチと似ていますが異なります。歴史的な側面を維持するために、タグを共有した後(つまり、共有リモートにプッシュした後)、それを本の別の場所に移動することは想定されていません。
CVSから来て、あなたが理解する必要があるのは、ブランチをセットアップするときにディレクトリを作成しなくなったことです。
「スティッキータグ」(1つのファイルにのみ適用可能)や「ブランチタグ」はもう必要ありません。
ブランチとタグはGitの2つの異なるオブジェクトであり、常にすべてのリポジトリに適用されます。
(今回はSVNを使用して)リポジトリを明示的に構造化する必要がなくなります。
branches
myFirstBranch
myProject
mySubDirs
mySecondBranch
...
tags
myFirstTag
myProject
mySubDirs
mySecondTag
...
その構造は、CVSがバージョンシステムではなくリビジョンシステムであるという事実に由来しています(ソース管理とリビジョン管理?を参照)。
つまり、ブランチはCVSのタグ、SVNのディレクトリコピーを介してエミュレートされます。
あなたがタグをチェックアウトし、その中で働き始めることに慣れているなら、あなたの質問は理にかなっています。
すべきではありません;)タグは不変
のコンテンツ
を表すことになっています。タグにアクセスするためにのみ使用され、毎回同じコンテンツを取得することが保証されています。
Gitでは、改訂の履歴は一連のコミットであり、グラフを形成します。
ブランチはそのグラフの1つのパスです
x--x--x--x--x # one branch
\
--y----y # another branch
1.1
^
|
# a tag pointing to a commit
すべての技術については、 JakubNarębskiの回答を参照してください。ただし、率直に言って、現時点では、(まだ)すべての詳細は必要ありません;)
重要な点は、タグはコミットへの単純なポインターであり、その内容を変更することは決してできないということです。ブランチが必要です。
あなたの場合、各開発者は特定の機能に取り組んでいます。
同僚のブランチを直接追跡する代わりに、この特定の機能のために全員の作業を統合して共有するために、全員が自分の作業をプッシュする1つの「公式」中央リポジトリのブランチのみを追跡できます。
枝は木でできており、木の幹から成長します。タグは紙(木の派生物)でできており、木のさまざまな場所からクリスマスの飾りのようにぶら下がっています。
プロジェクトはツリーであり、プロジェクトに追加される機能はブランチ上で成長します。答えはブランチです。
説明する最良の方法は、タグが読み取り専用ブランチとして機能することです。ブランチをタグとして使用できますが、誤って新しいコミットで更新する可能性があります。タグは、存在する限り、同じコミットを指すことが保証されています。
私はブランチをあなたが行くところ、タグをあなたが行った場所と考えるのが好きです。
タグは、バージョンリリースなど、過去の特定の重要なポイントのブックマークのように感じられます。
ブランチはプロジェクトが下がる特定のパスであるのに対し、ブランチマーカーはあなたと一緒に進みます。完了したら、ブランチ(つまりマーカー)をマージ/削除します。もちろん、その時点で、そのコミットにタグを付けることを選択できます。
タグは、署名付きまたは署名なしのいずれかです。ブランチが署名されることはありません。
署名されたタグは、特定のコミットに(署名を使用して)暗号的にバインドされているため、移動できません。署名されていないタグはバインドされておらず、移動することは可能です(ただし、タグの移動は通常のユースケースではありません)。
ブランチは別のコミットに移動できるだけでなく、移動することが期待されています。ローカル開発プロジェクトにはブランチを使用する必要があります。「タグ上で」Gitリポジトリに作業をコミットすることはまったく意味がありません。
簡単な答えは次のとおりです。
ブランチ:現在のブランチポインタは、リポジトリへのコミットごとに移動します
しかし
タグ:タグが指すコミットは変更されません。実際、タグはそのコミットのスナップショットです。
Gitのたとえ話は、典型的なDVCSがどのように作成されるのか、そしてなぜ彼らの作成者が彼らがしたことをしたのかを説明しています。また、Git forComputerScientistをご覧になることをお勧めします。ブランチやタグなど、Gitの各タイプのオブジェクトが何をするかを説明します。
タグはバージョンをマークするために使用されます。より具体的には、ブランチ上の特定の時点を参照します。ブランチは通常、プロジェクトに機能を追加するために使用されます。
を使用しております
branches
dev
機能開発またはバグ修正のための環境でlightweight tags
test
機能ブランチの環境用annotated tags
リリース/prd(メインブランチ)の場合注釈が付けられた各タグの後、すべての機能ブランチはメインブランチからリベースされます。
他の人が言っているように、abranch
は開発のラインであり、head
新しいコミットが到着するにつれて前進します。これは機能開発に理想的です。
Lightweight tag
は特定のコミットに固定されているため、内部バージョンを作成し、開発の完了後にqaチームが機能をテストできるようにするのが理想的です。
Annotated tag
テストされた機能ブランチをメインブランチ(安定版)にマージするときに正式なメッセージやその他のアノテーションを追加できるため、本番環境へのリリースに最適です。