GitHubでプロジェクトのバージョンを制御するにはどうすればよいですか

今日、GitHubでできる限り多くの時間を費やして（実際に仕事をしているチームの唯一の人でも）、実際の企業アプリケーションにどのようになるかを実際に感じています。

私が持っている1つの質問は、バージョンを制御することです。プロジェクトを始めたとしましょう。次に、チームメンバーはいくつかのブランチを作成し、そこで開発しました。本番の準備ができたら、すべてのブランチをmasterブランチにマージしました。最後に、versionでライブを開始し1.0ます。

現在、そのバージョン1.0は公開されており、そのバージョンのソフトウェアに関していくつかの問題が報告されています。1.1プロジェクトを急いで導入した問題を修正するために、バージョンの開発を開始したいと思います。

さて、質問はこれです：

ここでバージョニングをどのように制御する必要がありますか？

新しいブランチを作成し、そこにソフトウェアv1.0のバージョン1.0を保持し、いくつかのブランチで開発する（またはしない）場合、それらをマージしmaster、バージョンを公開する必要があり1.1ますか？

そのような状況に慣習はありますか？

私は次のブランチモデルを見つけました（そして採用し始めました）。

^{（記事の画像）}

その記事には多くの素晴らしい慣習と厳格なルールが記載されていますが、私はそれを強くお勧めします。

興味がある点：

• マスターブランチは、バージョンにタグを付ける場所です。ここでは開発は行われません。運用環境で展開されたバグの場合、修正プログラムブランチでバグを修正し、新しいバージョンにマージしてタグを付けます。
• 開発は、開発ブランチと機能ブランチで行われます。個人的には、develブランチと機能ブランチの機能のバグ修正を行っています。
• ソフトウェアがリリースに到達し始めたら、リリースブランチに分岐します。リリースブランチは、私が最後の仕上げをする場所です。バージョン番号のバンプ、メタデータの変更など。そして、マイナーなバグ修正。終了したら、マスターにマージし、タグを付けてバージョンと呼びます。
• 2つの主要なブランチ：マスターは「聖なるブランチ」です。HEADは常に最新の製品コードであり、developは夜間のブランチです。そのHEADは常にコードへの最新の（ただし不安定な可能性のある）追加を反映します。

特定のケースでは、手順はそのバージョンがどれほど急いだかによって異なります。残された機能があれば、私は開発版のリリースに戻り、すべてをやり直します。デプロイされたバージョンにバグがある場合、ホットフィックスブランチに分岐し、バグを修正し、マージしてv1.1にタグを付けます。両方の場合、最初にバグを修正し、次に説明されているように機能を追加します。

私がほとんど目撃しているのは：

• マスターはあなたのための製品です。最終的には、将来のバージョンx.0がすべてマスターになります。
• 本番環境の各バージョンにタグ/ブランチを作成して、それを必要とする顧客向けにサポートできるようにします。
• どちらか一方から修正をマージすることは、ケースごとに対処することです。