現在、Pro Gitを読んでGitの使用方法を学んでいます。今、私は分岐とタグについて学んでいます。私の質問は、いつブランチを使用する必要があり、いつタグを使用する必要があるかです。

たとえば、プロジェクトのバージョン1.1のブランチを作成するとします。このバージョンを終了してリリースしたら、ブランチを残してリリースバージョンをマークする必要がありますか？または、タグを追加する必要がありますか？タグを追加する場合、バージョンブランチを削除する必要があります（マスターまたは他のブランチにマージされていると仮定します）。

要するに、ベストプラクティスは分岐して、頻繁にマージし、常に同期を保つことです。

マスターブランチとは別のブランチにコードを保持することに関して、かなり明確な規則があります。

1. 重大な変更または破壊的な変更を実装しようとしています
2. 使用されない可能性のあるいくつかの変更を行おうとしています
3. あなたはそれがうまくいくかわからない何かで実験したい
4. あなたが分岐するように言われたとき、他の人はマスターで行う必要がある何かを持っているかもしれません

経験則は、分岐後です。マスターブランチと同期を保つ必要があります。結局、それをマスターにマージする必要があるからです。マージバックする際の巨大で複雑な混乱の混乱を避けるために、頻繁にコミットし、頻繁にマージする必要があります。

従うべき良い習慣

Vincent Driessenによる成功したGit分岐モデルには良い提案があります。この分岐モデルが魅力的な場合は、gitのフロー拡張を検討してください。他はフローについてコメントしました。

タグ付けの慣行

既にご存知のように、Gitは1.0-2-g1ab3183のようなコミット識別子を提供しますが、これらはタグではありません！タグ付けはgitタグで行われ、gitタグを使用して作成されたタグは、git describeが作成するコミット識別子のベースになります。言い換えると、Gitではブランチにタグを付けません。コミットにタグを付けています。タグは、コミットへの注釈付きポインタにすぎないと言うのは正しいことです。

それを実証した実際の例を見てみましょう。

                        /-[v1.0]
                       v
---.---.---.--- S ---..--- A <-マスター
                         \ 
                           \ -.--- B <-テスト

タグ「v1.0」が指すコミット「S」をコミットしましょう。このコミットは、ブランチ「マスター」とブランチ「テスト」の両方にあります。コミット 'A'（ 'master'ブランチの上部）で" git describe " を実行すると、次のようになりv1.0-2-g9c116e9ます。コミット 'A'（別名 'test'ブランチ）の上部で "git describe"を実行するv1.0-2-g3f55e41と、デフォルトのgit-describe設定の場合のようになります。この結果はわずかに異なることに注意してください。 v1.0-2-g9c116e9は、ソートされたSHA-1 idの9c116e9コミットで、tagの後に2コミットでコミットしていることを意味しv1.0ます。タグはありませんv1.0-2！

タグをブランチ「マスター」にのみ表示する場合は、「テスト」ブランチのブランチポイントの後に新しいコミットを作成できます（GIT-VERSION-FILEのデフォルト/フォールバックバージョン情報のみを更新するなど）。「test」ブランチのコミットに「v1.0.3」などのタグを付けると、「test」からのみ表示されます。

参照資料

学ぶべき多くの有益なブログや投稿を見つけました。ただし、専門的に説明されているものはまれです。したがって、@ nvieによる成功したGit分岐モデルという投稿をお勧めします。彼のイラストを借りました:)

2つの異なるバージョンのリポジトリが同時に存在する場合、ブランチが使用されます。タグは、リポジトリ内の特定の時点をマークする方法です。

タグを追加して、リリース済みバージョンをマークする必要があります。そのリリースのバグを修正する必要がある場合は、タグにブランチを作成します。

HEAD [または他のブランチ]にマージされたブランチのみを削除したい場合。