私は現在gitに移行しようとしていますが、私たちが現在svnタグを使用している方法に優雅な解決策を見つけることはできません。私の現在のリポジトリでは、私がリリースを1-1.nあるすべてのgitタグをチェックします
tags
tags/1
tags/1.1
tags/1.n
tags/live
tags/library
tags/library/1
tags/library/2
を持って、私はライブに最新のリリースをマージすると、ライブラリは各バージョンが使用する可能性ライブラリが含まれています。私はgitで1.nタグを作成する方法を理解していますが、ライブタグとライブラリタグを作成する方法を調べるのには苦労しています。
私はこのために別のレポを持っていて、サブモジュールとして1-1.nからタグを引き出すべきですか、それともgitで直接行うことができますか？
liveはタグではなく、ブランチである必要があります。単にブランチとタグをシンプルなツリーコピー操作として扱うsvnとは異なり（gitで扱う慣習とは区別されます）、gitのブランチとタグは単に特定のコミットへのポインタに過ぎず、主要な違いはアクティブなブランチがコミット後に続くのに対し、タグは常に作成されたコミットにとどまっていることです。
ライブラリディレクトリはブランチまたはタグではありません。おそらくgitサブモジュールで置き換えることができますが、扱うのが面倒な小さなバグですので、一般的なgitワークフローでスキルを上げるまで、それらをはっきりさせたいかもしれません。私を間違えないでください。サブモジュールは第三者の依存関係を管理するための正確なツールですが、慣れ親しんだgitモデルについて強い直観を持っていなければ、まったく不思議で壊れてしまいます。
もっと一般的に言えば、svnからgitに行くときに失う大きな問題は、事前に確立されたワークフローの利便性です。 Gitを使うと、一般的なsvnワークフローに従うことができますが、gitの使い方に何らかの制約を加えないと、歴史の卵を簡単にスクランブルすることができます。非常に効果的なワークフローhereが見つかります。これは唯一の可能なワークフローではなく、自分の状況に最適なものではないかもしれませんが、独自のワークフローを構築する出発点として役立つかもしれません。たとえば、svnから移動した当店では、masterのコミットの大部分をやっており、developブランチを使用し、masterの代わりにreleaseブランチにタグを付けています。したがって、私たちのワークフローは基本的には同じですが、長寿命ブランチの名前の選択肢が異なります。
これは本当に便利で素晴らしいスタートですが、gitが実際に私たちが望むことをやり遂げることはできないように思えます。 –
@JakeStride、gitのタグはどのディレクトリにもありません。あなたのリポジトリとタグはリポジトリ内の特定のコミットのポインタです。 gitのコミットは線形ではないので、これはgitでfinを動作させます.1つのコミットにはいくつかの先行と後継があります。 – svick
@ JakeStride：あなたはそうですが、一般に、ディレクトリにタグを表す必要はありません。タグは、意味のある名前で特定のコミットをマークする単なる方法です。タグを 'git tag'と同じように簡単にリストし、' git checkout
履歴が変更された場合は、タグであってはなりません。そして、図書館は自分のタグに入れてはいけません。それらは、リポジトリの通常の構造の一部であるか、または異なるリポジトリにある必要があります。言い換えれば、あなたの手に混乱があり、それを理にかなった方法でgitに変換するのは簡単ではないかもしれません。 – svick
svnでは、このフォルダ構造はデプロイメントスタックで動作し、同じマシン上で異なるバージョンを実行することができます。これは最高の構造ではありませんが、必要なものに対してはうまく機能します。 –
@ JakeStride問題は、svn *でタグを呼び出しているものがタグ*ではなく、実際にタグが分かっているVCSでタグとして使用できないということです。それはちょうどsvnが無知であり、古いものをタグと呼ぶことができます。 – hobbs