プロジェクト管理

強化されたGitフローの説明

不注意でGitに損傷を与えることは、非常に簡単です。それでも、使用するための最良の方法行く常に物議を醸すでしょう。

これは、Git自体が基本的な分岐操作の詳細のみを示しており、その使用パターン、つまり分岐モデルはユーザーの意見の問題であるためです。 Git分岐モデルは、ソフトウェア開発者がコードベースに変更を加えるときに必然的に発生する混乱を整理することで、苦痛を和らげることを約束します。

多くの開発者と同様に、実際のソフトウェア開発に取り掛かることができるように、「正しく機能する」ものが必要でした。だからあなたは拾った Gitフロー 、Gitユーザーによく推奨される分岐モデル。たぶん、実際にGitフローのロジックに問題が発生するまで、最初はGitフローのロジックに参加していました。あるいは、Gitフローはあなたがそれを採用するのに十分に適しているようには思えないかもしれません。結局のところ、無数の変数が関係しており、すべての状況で単一の分岐モデルがうまく機能するわけではありません。

朗報です！古典的なGitフローモデルのバリエーション、 強化されたGitフロー 主な利点を維持しながら、Gitフローワークフローのより一般的な操作を簡素化します。

古典的なGitフローモデルの素晴らしさと悲惨さ

で進化する製品を開発するときにGitフローがどのように優れているかを発見して以来、私はGitフローを強く支持してきました。 有意な値の増分 （言い換えると、 リリース ）。

値の大幅な増加は、で通常使用される2週間以上のスプリントのように、完了するまでにかなりの時間を必要とします。スクラムベースの開発。開発チームがすでに本番環境にデプロイされている場合、次のリリースのスコープが本番環境のコードと同じ場所（たとえば、使用するGitリポジトリのメインブランチ）に蓄積されると、問題が発生する可能性があります。

製品がまだ初期開発段階にある間、つまり、製品の生産も実際のユーザーもいない間は、チームがすべてをメインブランチ内に保持するだけで問題ありません。実際、それは大丈夫ではありません。この戦略により、多くの儀式なしで最速の開発ペースが可能になります。しかし、実稼働環境では状況が変わります。それから、実際の人々は安定するために製品に依存し始めます。

たとえば、本番環境に重大なバグがあり、すぐに修正する必要がある場合、修正を展開するためだけに、これまでにメインブランチで発生したすべての作業をロールバックしなければならないことは、開発チームにとって大きな災害になります。また、適切なテストを行わずにコードをデプロイすることは、コードが中途半端なものであるか、十分に開発されていると見なされるかにかかわらず、明らかに選択肢ではありません。

そこで、Gitフローを含む分岐モデルが光ります。洗練された分岐モデルは、次の方法に関する質問に答える必要があります。 分離する 現在人々が使用しているシステムのバージョンからの次のリリース、方法更新次のリリースでのそのバージョンとその方法 修正プログラムを導入する 現在のバージョンに対する重大なバグ。

Gitフロープロセスは、「メイン」（本番または「現在のバージョン」ブランチ）と「開発」（開発または「次のリリース」ブランチ）を分離し、機能/リリース/ホットフィックスブランチの使用に関するすべてのルールを提供することで、これらの基本的なシナリオに対処します。これは、リリースベースの製品の開発ワークフローからの多くの頭痛の種を効果的に解決します。

デザインのさまざまな例の原則

しかし、古典的なGitフローモデルに適したプロジェクトでも、それがもたらす可能性のある典型的な問題に苦しんでいます。

Gitフローは複雑で、2つの長寿命のブランチ、3種類の一時的なブランチ、およびブランチが相互に処理する方法に関する厳格なルールがあります。このような複雑さは間違いを起こしやすくし、それらを修正するために必要な労力を増やします。
リリースブランチとホットフィックスブランチでは、「ダブルマージ」が必要です。一度メインに、次に開発に。時々、あなたは両方をするのを忘れることができます。スクリプトまたはVCSGUIクライアントプラグインを使用してGitフローの分岐を簡単にすることができますが、特定のプロジェクトに関与するすべての開発者のすべてのマシンに対して最初にそれらを設定する必要があります。
CI / CDワークフローでは、通常、リリースの最終ビルドが2つになります。1つはリリースブランチ自体の最新のコミットからのもので、もう1つはメインへのマージコミットからのものです。厳密に言えば、メインのものを使用する必要がありますが、通常、2つは同一であるため、混乱する可能性があります。

「EnhancedGitFlow」と入力します

拡張Gitフローを初めて使用したのは、グリーンフィールドのクローズドソースプロジェクトでした。私は他の1人の開発者と協力していて、メインブランチに直接コミットすることでプロジェクトに取り組んでいました。

注：製品の最初の公開リリースまでは、開発ワークフローの速度と単純さのために、Gitフローの支持者であっても、すべての変更をメインブランチに直接コミットすることは絶対に理にかなっています。まだ本番環境がないため、チームができるだけ早く修正する必要がある本番環境のバグの可能性はありません。したがって、古典的なGitフローが意味するすべての分岐魔法を実行することは、この段階ではやり過ぎです。

その後、最初のリリースに近づき、その時点を超えると、メインブランチに直接コミットすることに不安を感じることに同意しました。私たちはかなり急速に動き、ビジネスの優先事項は、堅実な開発プロセスを確立する余地をあまり残していませんでした。つまり、メインブランチがリリース可能な状態にあることを確信できる十分な自動テストを備えたプロセスです。

これは、古典的なGitフローモデルの有効なケースのようでした。メインブランチと開発ブランチが別々であり、値が大幅に増加するまでの時間が十分にあるため、ほとんどの場合、手動のQAで十分な結果が得られると確信していました。私がGitフローを提唱したとき、同僚は似たようなものを提案しましたが、いくつかの重要な違いがあります。

最初、私は押し返しました。古典的なGitフローに対して提案された「パッチ」のいくつかは少し革命的すぎるように思えました。私は彼らが主要な考えを破るかもしれないと思いました、そして全体のアプローチは不十分でしょう。しかし、さらに考えてみると、これらの調整は実際にはGitの流れを壊さないことに気づきました。一方、上記のすべての問題点を解決することで、より優れたGit分岐モデルになります。

そのプロジェクトで変更されたアプローチで成功した後、私はその背後に小さなチームがいる別のクローズドソースプロジェクトでそれを使用しました。そこでは、私は永続的なコードベースの所有者であり、外部委託された開発者または2人が時々助けました。このプロジェクトでは、6か月で本番環境に移行し、それ以来、CIおよびE2Eテストを1年以上使用しており、毎月リリースされています。

拡張Gitフローを使用する場合の典型的なGitコミットグラフ。グラフは、開発とメインでのいくつかのコミットと、それらの一般的なコミットの前に、いくつかの日付ベースのタグを示しています。

この新しい分岐アプローチに関する私の全体的な経験は非常にポジティブだったので、他の開発者と共有して、古典的なGitフローの欠点を回避できるようにしたいと思いました。

従来のGitフローとの類似点：開発の分離

強化されたGitフローでの作業の分離については、メインと開発の2つの長寿命のブランチがまだあります。（ユーザーはまだ修正プログラムとリリース機能を持っています。これらはブランチではなくなったため、「機能」に重点を置いています。詳細については、違いのセクションで説明します。）

ウェブデザインのcmsとは

従来のGitフロー機能ブランチの正式な命名スキームはありません。機能の準備ができたら、開発から分岐してマージし直して開発します。チームは、任意の命名規則を使用できます。または、開発者が「my-branch」よりもわかりやすい名前を使用することを単に望んでいます。強化されたGitフローについても同じことが言えます。

あるカットオフポイントまで開発ブランチに蓄積されたすべての機能が、新しいリリースを形作ります。

スカッシュマージ

ほとんどの場合、履歴を適切かつ線形に保つために、機能ブランチにスカッシュマージを使用することを強くお勧めします。これがないと、チームがほんの一握りの機能ブランチをジャグリングしているときに、コミットグラフ（GUIツールまたはgit log --graphから）がだらしなく見え始めます。

スクラムチームの推奨サイズ

スカッシュマージ戦略から得られたコミットグラフを、マージコミット戦略から得られたものと比較します。開始Gitコミットグラフには、ラベルが付けられたプライマリブランチがあります

ただし、このシナリオのビジュアルに問題がない場合でも、潰す理由はもう1つあります。押しつぶさずに、履歴ビューをコミットします。どちらもプレーンですgit log （--graphなし）およびGitHub-最も単純なマージシナリオでも、かなり一貫性のないストーリーを伝えます。

スカッシュマージ戦術から得られたコミット履歴ビューを、マージコミット戦術から得られたビューと比較します。元のリポジトリの状態はタイムライン形式で示され、共通のコミットからの2つの機能ブランチへのコミットの時系列を示します

スカッシュマージを使用する際の注意点は、元の機能のブランチ履歴が失われることです。ただし、この警告は、たとえばGitHubを使用している場合にも当てはまりません。完全な元の履歴を公開します機能ブランチ自体が削除された後でも、スカッシュマージされたプルリクエストを介した機能ブランチの。

従来のGitフローとの違い：リリースとホットフィックス

（うまくいけば）それがあなたがする主なことなので、リリースサイクルを見てみましょう。開発で蓄積されたものをリリースしたいところまで来たら、それは厳密にはメインのスーパーセットです。その後、クラシックと拡張Gitフローの最大の違いが始まります。

強化されたGitフローで通常のリリースを実行すると、変化するGitコミットグラフ。最初のグラフは、チップの背後で複数のコミットを開発することと、1つのコミットによって主に分岐しています。タグ付け後、mainとvYYYY-MM-DDは互いに均等になります。ローカルメインを削除し、開発、強制プッシュ、デプロイ、テストなどの先端で作成した後、メインは開発でも表示され、メインが元々あった場所にvYYYY-MM-DDが残ります。デプロイ/テストサイクルの後、メインのステージング修正（最終的にはスカッシュが開発にマージされます）、および開発の無関係な変更、最終的なグラフは開発され、メインが分岐し、それぞれがいくつかのコミットを持ち、前のグラフ。

拡張Gitフローでのリリース

強化されたGitフローを使用してリリースを作成するすべてのステップは、従来のGitフロープロセスとは異なります。

リリースは、開発ではなくメインに基づいています。 メインブランチの現在の先端にタグを付ける 何か意味のあるもので。現在の日付に基づいて、接頭辞「v」が付いたISO8601形式のタグを採用しました。例： v2020-09-09 。
- 修正プログラムなど、1日に複数のリリースが発生した場合、必要に応じて、フォーマットに連番または文字を付けることができます。
- 一般に、タグはリリース日に対応していないことに注意してください。これらは、Gitに、次のリリースプロセスが開始されたときにメインブランチがどのように見えたかを参照するように強制するためだけのものです。
タグを押す git push origin を使用します。
その後、少し驚きました： ローカルメインブランチを削除します 。間もなく復元するので、心配しないでください。
- mainへのコミットはすべて安全です。前の手順でmainにタグを付けることで、ガベージコレクションからそれらを保護しました。これらのコミットのすべて（後で説明する修正プログラムも含む）も開発の一部です。
- チームの1人だけが特定のリリースでこれを実行していることを確認してください。それがいわゆる「リリースマネージャー」の役割です。リリースマネージャーは通常、最も経験豊富な、および/または最も上級のチームメンバーですが、チームは、特定のチームメンバーがこの役割を永続的に引き受けることを避けるのが賢明です。チーム間で知識を広め、悪名高い人を増やす方が理にかなっていますバスファクター。
開発ブランチのチップコミットで新しいローカルメインブランチを作成します 。
git push --forceを使用してこの新しい構造をプッシュします 、リモートリポジトリはそのような「大幅な変更」をそれほど簡単には受け入れないためです。繰り返しになりますが、これは、次の理由により、このコンテキストで見られるほど安全ではありません。
- メインブランチポインタをあるコミットから別のコミットに移動するだけです。
- 一度に1人の特定のチームメンバーだけがこの変更を行っています。
- 毎日の開発作業は開発ブランチで行われるため、メインをこのように移動しても、他の人の作業を中断することはありません。
新しいリリースがあります！ ステージング環境にデプロイします そしてそれをテストします。（便利なCI / CDパターンについては以下で説明します。）修正はメインブランチに直接送られ、そのために開発ブランチから分岐し始めます。
- 同時に、開発ブランチで新しいリリースの作業を開始できます。これは、従来のGitフローで見られるのと同じ利点です。
- この時点で現在本番環境にあるもの（ステージングの今後のリリースではない）に修正プログラムが必要な場合は、以下の「アクティブリリース中の修正プログラムの処理...」でこのシナリオの詳細を確認してください。
新しいリリースが十分に安定していると見なされたら、 最終バージョンを実稼働環境にデプロイします そして、メインの単一のスカッシュマージを実行して開発します すべての修正を取得します。

強化されたGitフローのホットフィックス

修正プログラムのケースは2つあります。修正プログラムを実行している場合 アクティブなリリースがない場合 —つまり、チームは開発ブランチで新しいリリースを準備しています—それは簡単です。メインにコミットし、変更をデプロイして、準備が整うまでステージングでテストしてから、本番環境にデプロイします。

最後のステップとして、メインからコミットを選択して開発し、次のリリースにすべての修正が含まれるようにします。複数の修正プログラムのコミットが発生した場合、特にIDEまたは他のGitツールでパッチを作成して適用することで、何度もチェリーピッキングを行う代わりに、労力を節約できます。最初のリリース後にマージメインを押しつぶして開発しようとすると、開発ブランチで行われた独立した進捗状況と競合する可能性が高いため、お勧めしません。

修正プログラムの処理 アクティブリリース中 つまり、メインを強制的に押しただけで、まだ新しいリリースを準備している場合は、強化されたGitフローの最も弱い部分です。リリースサイクルの長さと解決する必要のある問題の重大度に応じて、常に新しいリリース自体に修正を含めることを目指してください。これが最も簡単な方法であり、ワークフロー全体をまったく混乱させることはありません。

それがうまくいかない場合（修正をすばやく導入する必要があり、新しいリリースの準備が整うのを待つことができない場合）、やや複雑なGit手順の準備をします。

需要の価格弾力性を見つける方法

ブランチを作成します。これを「新リリース」と呼びますが、チームはここで任意の命名規則を採用できます。これは、メインの現在のヒントと同じコミットです。新規リリースをプッシュします。
現在アクティブなリリース用に以前に作成したタグのコミット時に、ローカルメインブランチを削除して再作成します。メインを強制的に押します。
mainに必要な修正を導入し、ステージング環境にデプロイして、テストします。準備ができたら、本番環境にデプロイします。
チェリーピッキングまたはパッチを使用して、現在のメインリリースから新しいリリースへの変更を伝達します。
その後、リリース手順をやり直します。現在のメインの先端にタグを付けてタグをプッシュし、新しいリリースブランチの先端にあるローカルメインを削除して再作成し、メインを強制的にプッシュします。
1. 前のタグはおそらく必要ないので、削除できます。
2. 新しいリリースのブランチは冗長になっているため、削除することもできます。
これで、新しいリリースでいつものようにうまくいくはずです。最後に、緊急修正プログラムをメインから伝播して、チェリーピッキングまたはパッチを介して開発します。

強化されたGitフローの下でアクティブリリース中にホットフィックスを実行すると変化するGitコミットグラフ。開始グラフは、コミットの最長行として展開され、メインは2つのコミットを1つのコミットで分岐し、その前に3つのコミットを分岐し、ブランチはv2020-09-18のタグが付けられた1つのコミットで分岐します。上記の最初の2つの手順の後、グラフにはmainがあった場所に新しいリリースがあり、mainはv2020-09-18でもありません。その後、残りの手順が実行され、最終的なグラフが作成されます。ここで、mainは、新しいリリースがあった場所よりも前のコミットであり、v2020-09-20は、v2020-09-18があった場所よりも前のコミットです。

適切な計画、十分に高いコード品質、健全な開発とQA文化があれば、チームがこの方法を使用する必要はほとんどありません。万が一に備えて、Gitフローを強化するためにこのような災害計画を作成してテストすることは賢明でしたが、実際に使用する必要はありませんでした。

強化されたGitフローに加えてCI / CDをセットアップ

すべてのプロジェクトに専用の開発環境が必要なわけではありません。各開発者マシンに高度なローカル開発環境をセットアップするのは簡単かもしれません。

しかし、専用の開発環境は、より健康的な開発文化に貢献することができます。開発ブランチでテストを実行し、テストカバレッジを測定し、複雑さのメトリックを計算すると、多くの場合、ステージングに至る前にミスをキャッチすることで、ミスのコストを削減できます。

強化されたGitフローと組み合わせると、いくつかのCI / CDパターンが特に役立つことがわかりました。

開発環境が必要な場合は、CIをセットアップして、開発ブランチへのコミットごとにビルド、テスト、およびデプロイします。 E2Eテストをお持ちで、それがあなたのケースで理にかなっている場合は、ここでも適合してください。
メインブランチへのコミットごとに、CIをセットアップしてビルド、テスト、およびステージング環境にデプロイします。 E2Eテストは、この時点でも非常に有益です。
- 両方の場所でE2Eテストを使用することは冗長に思えるかもしれませんが、修正プログラムは開発では発生しないことに注意してください。 mainへのコミットでE2Eをトリガーすると、ホットフィックスがテストされます そして 外出する前の毎日の変更だけでなく、開発へのコミットをトリガーすると、バグを早期に発見できます。
チームが手動の要求に応じてメイン環境から本番環境にビルドをデプロイできるようにCIを構成します。

Gitフローが強化されたCI / CDの推奨セットアップ

このようなパターンは比較的単純ですが、日常の開発操作をサポートする強力な機械を提供します。

nodejsで何ができるか

強化されたGitフローモデル：改善と考えられる制限

強化されたGitフローは万人向けではありません。それは本枝を押す力の物議を醸す戦術を活用しているので、純粋主義者はそれを憤慨するかもしれません。ただし、実用的な観点からは、問題はありません。

前述のように、修正プログラムはリリース中はより困難ですが、それでも可能です。あまり頻繁に発生しないQAやテストカバレッジなどに適切な注意を払うことで、私の観点からは、従来のGitフローと比較した拡張Gitフローの全体的な利点との有効なトレードオフになります。大規模なチームや、修正プログラムがより頻繁に発生する可能性があるより複雑なプロジェクトで、強化されたGitフローがどのように機能するかを知りたいと思います。

強化されたGitフローモデルに関する私の前向きな経験も、主にクローズドソースの商用プロジェクトを中心に展開しています。プルリクエストがソースツリーの古いリリース派生に基づいていることが多いオープンソースプロジェクトでは、問題が発生する可能性があります。それを整理するための技術的な障害はありません。予想以上の労力が必要になる可能性があります。このような場合の拡張Gitフローの適用性に関して、オープンソーススペースで多くの経験を持つ読者からのフィードバックを歓迎します。

ApeeScapeの同僚に感謝しますアントワーヌファム強化されたGitフローの背後にあるアイデアを開発する上での彼の重要な役割に対して。

ApeeScapeエンジニアリングブログの詳細：

マイクロソフトゴールドパートナーバッジ。

としてマイクロソフトゴールドパートナー、ApeeScapeは、マイクロソフトの専門家のエリートネットワークです。必要なときに必要な場所で正確に、必要な専門家と一緒に高性能チームを構築してください！

基本を理解する

Gitフローとは何ですか？

Gitフローは、Gitバージョン管理システム（VCS）の分岐モデルです。分岐モデルは、基本的なGit操作に基づいて構築され、堅牢なバージョン管理を可能にすることを目的とした使用パターンを規定します。 Gitフローは、2010年にVincent Driessenのブログ記事で公表され、それ以来人気があります。

Gitフロー分岐戦略とは何ですか？

Gitフロー分岐戦略は、大幅な値の増分で進化する製品を開発するときに優れています。これは、「main」（本番または「現在のバージョン」ブランチ）と「develop」（開発または「次のリリース」ブランチ）を分離し、ヘルパーブランチの使用に必要なすべてのルールを提供することによって行われます。

Gitフローを使用するにはどうすればよいですか？

規定のパターンに従ってGitフローを使用します。これにより、チームは、現在本番環境にあるシステムのバージョンから次のリリースを分離する方法、そのバージョンを次のリリースで更新する方法、および重大なバグの修正プログラムを現在のバージョンに導入する方法に関する質問に答えることができます。

Gitフローを使用する必要がありますか？

Gitフローを使用する必要があるかどうかは、特定のプロジェクトによって異なります。答える主な質問は、「開発ワークフロー全体には、メインブランチをリリース可能な状態に保つのに十分な自動品質保証がありますか？」です。答えが「いいえ」の場合、そのようなプロジェクトはGitフローの恩恵を受ける可能性があります。