Gitは便利な分散VCSであるだけでなく、リリース準備ツールでもあります。
この記事では、例としてMavenのJavaプロジェクトを使用してフローを調べます。 この記事は、中小規模のチームの開発者に役立つ場合があります。これは、gitの基本的な知識を意味します。 マテリアルはgit-flowを部分的にエコーしますが、ここでは簡単なオプションについて説明します。
古典的なケースでは、リポジトリに1つのマスターブランチがあり、そこからアセンブリが作成されます。 プロジェクトがビルドサーバーで同時にビルドされている場合、これは混乱を招く可能性があります-同じバージョンでのいくつかの異なるビルド、リリースに分類される一連のコミットは明確ではありません（たとえば、VCSのトリガーに従ってアセンブリが自動的に行われる場合）。
この問題を解決する方法
最初にできることは、マスターから定期的なマージが行われる補助リリースブランチを導入することです（スクリーンショットは下から上へタイムラインでTortoiseGitで作成されます）。 Mavenプロジェクトの場合、pomファイルのマージ時に、スナップショットバージョンはリリースバージョンに置き換えられます。 正しく行われた場合、これが唯一の競合です。 バージョン番号とともにタグを配置することをお勧めします。 その後、SNAPSHOTバージョンのメジャーブランチはmasterブランチで作成されるため、masterは常にSNAPSHOTであり、releaseは常にそうではありません。 したがって、ビルドサーバーは製品アセンブリのリリースブランチで構成されます。
2つのブランチマスターとリリースのオプションの欠点は、マスターから新しい機能をリリースせずに修正プログラムを作成できないことです。これは重要な場合があります。
ホットフィックスブランチの紹介
これを行うには、リリースのマージに先行するコミットから成長する修正プログラムブランチを入力できます。 このスレッドの最初のコミットは、マイナーバージョンのスナップショットバージョンです（図の1）。 さらに、行われた修正はリリースおよびマスターブランチにマージされます。 リリースでのマージでは、非スナップショットマイナーバージョン（2）を修正することで唯一の競合が解決され、マスターでマージすると、バージョンはマスター（3）から残ります。 リリースのマージ後、マイナーアップスナップショットバージョン（4）が修正プログラムブランチで作成されます。 次のメジャーリリースの前に、ホットフィックスはマスターにマージされます。これにより、すべての修正が失われることはありません。 ブランチの準備が完了すると、ブランチは元のリポジトリに送信されます。
最後に何がありますか
ソリューションの主な利点：
- リリースのクリーンアップ。 1つのコミットが1つのリリースバージョンに対応する
- リポジトリの権利の規制により、チームの役割は明確に分けられています：開発者、レビューア、テスター/リリースマネージャー
- 通常の場合、プッシュする必要はありません-強制的に、他の人の編集を上書きするリスクがあり、貴重な変更を失う可能性は最小限です
- ビルドサーバーのテンプレートに従って定期的に新しい構成を作成する必要はありません（メジャーリリースごとに新しいブランチを作成するオプションとは異なります）
- このスキームは比較的簡単ですが、非常に便利です。 ほぼすべてのプロジェクトで、2つまたは3つのブランチのオプションを使用しています。
欠点には、以前のメジャーリリースで修正プログラムをリリースできないことが含まれます。 また、必要なコミットのみからリリースをダイヤルすることもできません。 これはフローを複雑にすることで解決され、この記事の範囲外です。
多くの人にとって、ここには新しいものは何もありませんが、同じgithubから判断すると、大部分のオープンソースプロジェクトは1つのブランチを持つ最も単純なスキームを使用しています。
また、どのフローを使用しますか？
便利なリンク： ProGit 、 Git How To