3つのアプローチ
これらの一般的な手法の1つを使用することも、独自の手法を作成するための基礎として使用することもできます。
GitHubフロー。この戦略は、GitHubサービスチームによって使用されます。主な要件は次のとおりです。
- マスターブランチのコードにエラーはなく、いつでもデプロイできる状態になっているはずです。
- 新しい機能の開発を開始するには、マスターブランチに機能ブランチを作成し、誰にでもわかりやすい名前を付ける必要があります。作業の準備ができたら、プルリクエストを介してマスターブランチにマージする必要があります。
- 変更をマージした後、すぐにサーバーにデプロイする必要があります。
このアプローチは通常、あまり頻繁に更新されない単一バージョンの製品に使用されます。たとえば、ウェブサイト。プラス面として、このアプローチにより、開発者は作業を理解して整理しやすくなります。主な欠点は、プロジェクトが十分に複雑で頻繁に更新される場合は、別の戦略を使用する方がよいことです。
GitFlow。この戦略は議論の余地があるとすぐに言わなければなりません。彼女については肯定的なレビューと否定的なレビューの両方がたくさんあります。
結論は次のとおりです。永続ブランチには、最新の現在のバージョンがどのように見えるかを理解するためのマスターブランチと、開発が行われている開発ブランチの2種類があります。そこから来る一時的な枝には3つのタイプがあります。
- 機能、新しい機能を追加します。作業が完了したら、開発ブランチでプルリクエストを作成する必要があります。
- 新しいバージョンで動作するようにリリースします。タイトルにバージョン番号を追加することが重要です。これにより、混乱を避け、変更を追跡できます。
- 迅速なバグ修正のためのHotfix。
このアプローチは、さまざまなプラットフォーム用の複数のバージョンが絶えず開発されているプロジェクトに最適なアプローチの1つと見なされています。
2010年に、オランダのプログラマーであるVincent Driessenのテキスト「 成功したGit分岐モデル」が公開され、そこで彼は最初にGitFlowについて話しました。この記事は非常に人気があり 、ロシア語の翻訳が登場し、多くのチームでこの方法が採用されました。
2020年に、アメリカのプログラマーであるGeorgeStokerが「 GitFlowの推奨をやめてください。"、彼はこの方法を現代の現実では時代遅れで効果がないと批判した。 Driessenはこれに応えて、2010年のテキストを免責事項で補足し、彼の方法は万能薬ではなく、作業を整理するための選択肢の1つにすぎないと認めました。
フォークワークフロー。ここでのアプローチは次のとおりです。すべての変更をマージするための元のリポジトリとそのコピーがあり、そこで別の開発者が作業します。このアプローチはオープンソースのイデオロギーに非常に近く、その目標はプロジェクト内のオープンソースコミュニティのすべての利点を利用することです。ただし、分岐ワークフローのほとんどはGitFlowをコピーしています。ここの機能ブランチは、ローカルの開発者リポジトリとマージされます。したがって、請負業者がいる非常に大規模なチームでも開発が柔軟になります。
人々の中に 、このアプローチを取るのLinuxです。システムコアの場合でも、コードを変更するための独自のオプションを提供できます。そして、このアプローチは効果的に機能しているようです。
一般的なポイント
どちらのコンセプトを選択する場合でも、守るべき基本的なポイントがあります。たとえば 、Microsoftのルールは次のとおりです。
- ブランチ戦略を過度に複雑にしないでください。
- すべての更新とバグ修正に機能ブランチを使用します。
- プルリクエストを使用して、機能ブランチをメインブランチにマージします。
- アップストリームの品質と最新性を維持します。
これらのアイデアに基づく戦略により、チームは論理的で理解しやすいバージョンで作業するようになります。
ここにいくつかのより役立つガイドラインがあります。
それをシンプルで明白と呼ぶ
これは、すべてのチームメンバーが誰が何に取り組んでいるかを正しく理解するのに役立ちます。ブランチ名に、作成者の名前などの追加情報を含めることもできます。これは、オリジナルのものを思いつく必要がない場合です。「users」、「bugfix」、「feature」、「hotfix」などのブランチ名が必要です。遅延するブランチの場合は、個別の特別なフラグを使用します。これにより、チームは何が問題になっているのかをすぐに理解し、これらのタスクを常に長期的に念頭に置くことができます。
プルリクエストを介してのみブランチをマージする
プルリクエストメカニズムは論理的でよく考えられていることが証明されています。このプロセスには時間がかかるため、プルリクエストのすべての参加者から何をどのような時間枠で期待するかについてチーム内で合意する必要があります。レビューアの責任を分散し、内部のナレッジベースを通じてチームと共有します。
ここにいくつかの特定のヒントがあります：
- Microsoftの調査によると、レビューアの最適な数は2人です。
- チームがすでにコードレビューの原則を形成している場合は、それらに固執し、破らないようにしてください。
- より多くのチームメンバーが定期的にコードのレビューを担当している場合、プルリクエストははるかにうまく機能します。
- レビュー担当者がコンテキストをすばやく把握できるように、作業の説明を十分に詳細に残してください。
ブランチポリシーを設定する
いくつかの理由から、ポリシーの分岐に時間を費やす価値があります。
- このようにして、現在の作業をメインブランチ内の完了した作業から分離できます。
- 特定のブランチに誰がどのような変更を加えることができるかを決定することにより、合理的な制限を行います。
- 効果的な作業方法を迅速に広めます。
どのポリシーを構成する必要があるかに基づいて、2つの主要なルールがあります。
- レビューアは、作成時にプルリクエストに自動的に追加されます。最初にそれらのリストを定義してから、進むにつれて編集することができます。
- プルリクエストを完了するには、ビルドが成功する必要があります。メインブランチに注がれたコードは、きれいに構築されるはずです。
しかし、ブランチ戦略を作成する際の最も重要な原則はこれです。チームがこれまたはそのアクションの意味について質問しないように、それを検討する必要があります。そうすれば、プロジェクトの毎日が生産的になります。
ブログ ITGLOBAL.COM-マネージドIT、プライベートクラウド、IaaS、ビジネス向けの情報セキュリティサービス：