gitの最初のメジャーリリース

Question

私はちょうどgitの製品のV1.0.0をリリースしました。私は今から推奨されるアドバイスが何であるか疑問に思っています。

私はv1.0.0ブランチを作成するのですか、またはv1.0.0の注釈付きタグですか、より良い選択肢ですか？

タグは私にとって正しいアプローチだと思われますが、私はタグからの分岐とマージのワークフローが不安です。

Answer 1

を使用します。

支店は仕事のためにある、タグがリリースのためのものです。

あなたのメインライン支店（通常はマスター）は、次のリリースのための継続的なフォワード開発である必要があります。リリースが行われるたびに、イベントをマークするタグ（最小限注釈）を使用します。

次のバージョンの作業中に、リリースされたバージョンのメンテナンスリリースを行う必要がある場合は、タグをチェックアウトし、そのポイントからブランチを作成できます。

git checkout -b <tag>-maintenance <tag> 

これにより、メンテナンス作業のための新しい支店が作成されます。メンテナンスリリースの作業が終了したら、メンテナンスブランチのリリースにタグを付けることによって、メンテナンスブランチで同じプロセスを実行します。

リリース（マスター）ブランチに他のフォワード開発がない場合は、そのブランチにメンテナンス作業を追加して、もう一度タグを付けて移動することができます。

Answer 2

依存しますが、次のバージョンでも作業している間にv.1.0.0をすぐに修正したいと思います。

すぐにブランチを作成します。あなたがそれを必要としないことはほとんどありません（v1.0.1を作成する必要がない場合のみ）。

もちろん、タグを付けて（傷つくことはありません）、後でそのタグに基づいてブランチを作成することもできます。単純にタグからブランチを作成することができます

git checkout -b 1.0.0 v1.0.0 

Answer 3

注釈付きタグがおそらく最初に行うべきことです。

そこから、ワークフローにはいくつかの選択肢があります。ここには最も一般的な2つのオプションがあります。

「前方互換」の開発スタイルに移行することができます。ここでは、1.0シリーズはこれ以上サポートされません（1）。 1.0シリーズでは "サポートのみ"を、2.0シリーズには新機能がすべて追加されます（あるいは、1.0.1と1.1の代わりに、2.0は完全な書き換えのために残されます - バージョン番号はそれほど重要ではありません） 。

シナリオ2は確かに「プロフェッショナル」な選択肢ですが、スコープが狭い小規模なプロジェクトの場合は、シナリオ1は大丈夫です。

シナリオ1では、すべての作業をマスターブランチで実行するか、フィーチャーブランチを実行して準備ができたらマスターにマージします。新しいリリースをお持ちの場合は、1.1または1.0.1などのタグを付けてください。

シナリオ2では、最新のリリース、サポートリリースを反映する「サポート」ブランチ、ステージングする「ステージング」ブランチ、最終的にマスタにマージされる新しい機能をテストするために、新機能の開発やバグ修正にフィーチャーブランチを使用することができます。また、バグ修正を導入すると、サポートブランチをマージしてマスターに戻します。新しいバージョンまたはサポートバージョンのいずれかをリリースするときは、注釈付きのタグをもう一度使用してください。

個人的には、私は通常、バージョン管理されたリリースごとにブランチを持つのではなく、タグ付きのマスターステージングサポートブランチに賛成です。しかし、それはgitの素晴らしいことです - あなたはそれを行うことができますが、フィット感がある！もちろん、私が提示した2つの選択肢は、開発ワークフローのための唯一のオプションではありません。

Answer 4

gitでいつでもブランチを作成することができます。私は、次の操作を行います：

1. は、私がバージョン1.0.0にいくつかの修正を追加する必要があるとき、私は私に基づいてブランチ「v1.0.0デベロッパー・メンテナンス」を作成し、タグ「v1.0.0デベロッパー」
2. を作成します。タグ。
3. 現在のバージョンに修正を適用する場合は、「v1.0をマージしてください。0-メンテナンスマスター 『」に』またはキャッチフレーズは、他の場所StackOverflowの上に発現されたチェリー選ぶ