gitはブランチバージョン管理に基づいています

クズども · 掲載地 2018/04/08 10:25:39

分岐ベースのバージョンについては、構成管理プロセスの全体像を完璧に示した以下の図について説明する必要があります。まず第一に、この図はGitモデルに基づいて書かれていますが、実際にはGitとSubversionはバージョン管理の概念を解明しています。ただし、Gitはブランチ管理や分散性能においてSubversionよりも質的に飛躍しています(ただし、この記事の焦点ではありません)。

このグラフの原理を紹介する前に、一般的なバージョン管理のための2つの異なる戦略について話しましょう。1つは「先駆者バックボーン、安定ブランチ」、もう1つは「安定バックボーン、パイオニアブランチ」です。名前の通り、安定版(本番版)で、幹線か枝幹かのどちらかに設置されます。 VSSを使用する従来のプロジェクトチームの場合、どのモードに属するかは判断が難しいです。主にVSS自体にはブランチ管理戦略がないため、多くのプロジェクトチームは本番環境と開発環境に対応した2つ(または3つ)のバージョンライブラリをそれぞれ構築しています。もちろん、これも一種のブランチ管理の仮面をかぶっています。しかし、バージョン管理ツールとしてSubversionやGitに切り替えると、多くのチームは安定トランクモードを使用します。つまり、トランク(トラックやマスター)は安定した本番環境に対応し、異なるリリースにタグを付けて本番バージョンを示します。個人的には、安定したバックボーンコードパターンが現時点で絶対的な主流のコードバージョン管理ソリューションであるべきだと思います。上の図は標準的な「安定バックボーン」管理モデルです。
マスター:対応するサブバージョンはトラックです。プロダクション版に対応して、リリースごとに1回タグ付けされます。
リリースブランチ(インテグレーションブランチとも呼ばれる):本番環境が更新されている限り、まずリリースブランチ(統合ブランチ)にマージする必要があります。これはプロジェクトチームが現在「プリプロダクション」や「シミュレーション環境」と呼んでいる概念にやや似ています。
開発ブランチ(開発ブランチまたはデベロップブランチ):開発環境が直面する環境。
特徴分岐(特徴分岐):独立した機能は、独立した開発部門から分離することができます。これは主に、一部の機能が更新に比較的長くかかることを考慮し、リリースや別々のブランチの遅延を避けたいためです。
ホットフィックスブランチ(バグ修正ブランチ)ここでのバグは主に制作上のバグです。
幹と枝を紹介した後、これらの枝の生成とマージの方向性を紹介する必要があります。
マスターは本番バージョンで、トランクはマージ用のブランチを2つしか受け入れません。1つはリリースブランチ(統合ブランチ)、もう1つはホットフィックスブランチです。他のブランチは本番ブランチに統合できません。
リリースブランチは、本番と同時に最初に作成されますが、本番環境と全く同じです。彼は開発部門と融合することを受け入れるだけです。つまり、彼は機能ブランチやバグフィックスブランチからの直接マージを受け入れていません。
開発部門、開発部門は統合部門と同様に、ある時点では本番環境と同じです。しかし、開発が進むにつれて、開発部門では新機能が引き続き追加されていく予定です。 Dev Theoryでは、2つのブランチのマージしか認められていません。1つはホットフィックス、もう1つはフィーチャーブランチです。
Feature Branchは、ある時点(バージョン)から開発ブランチと始まり、最終的にはFeature Branchが開発ブランチと統合されます。
バージョン管理手法をシナリオの形で簡単に紹介しましょう
本番バージョンがブランチ(dev、hotfixes、release)に分かれており、この時点で開発者は合計10の関数の開発を始めます。 10機能のうち8機能が開発されると、テストチームは内部テストに介入し、設定管理者は開発ブランチを開発環境に展開し、継続的統合ツールを通じてテストを行いました(ここでは別の話題です)。テスト検証で、単純な保険保険や請求申告など2つの機能が完全に受け入れられず再実行が必要であることが判明した際、開発部門から分離された2つの機能ブランチが分離され、そのシンプル保険保険とクレームリターンに対応し、開発ブランチでは対応するコードもロールバックする必要がありました(手動操作はこちら)。テストチームが開発ブランチのテストに問題がないと判断すると、UATの条件を満たしていると判断すると、設定管理者は開発ブランチをリリースブランチにマージし、継続的インテグレーションツールを使ってこのブランチをプレプロダクション環境に公開し、ユーザーにテストのために渡します。ユーザー検証で問題が見つかった場合、開発者は開発ブランチを修正し、リリースブランチにマージします(元の写真ではリリースブランチで直接修正されていますが、これは良くないと思います。開発者は開発者ブランチだけに向き合うことをお勧めします)。検証リリース検証プロセスがビルド環境に深刻なバグを発見し直ちに修正する必要がある場合は、ホットフィックスブランチで緊急修正し、正しいことを確認すると緊急に起動します。同時に、ホットフィックスブランチは開発版とマージされます(ここでは主に手動で行われています。なぜなら、現時点で本番版はすでに開発版と大きく異なっており、自動マージを完了するのが不可能なことが多いためです)。そしてその後、開発者版がリリースに統合されます。一定期間が経つと、クレーム返還機能は不要となり、キャンセルが必要になるため、クレーム返還機能のブランチは削除されます。もう一つの機能は保険が簡単に開発され、次のオンライン版で再び開発部門に統合されました。
上記のシナリオには、日常の開発、解き換え、緊急更新、その他の日々の開発プロセスが含まれます。

gitはブランチバージョン管理に基づいています

関連記事

閲覧したセクション