Gitの分岐戦略

この記事は、「Advanced Git」シリーズの一部です。 Twitterでフォローするか、今後の記事の最新情報についてはニュースレターを購読してください！

ほとんどのバージョン制御システム（VCS）は分岐をサポートします。基本的に、分岐は変更のための個別のワークスペースを作成し、メインコードベースに影響を与えることなく実験を可能にします。 GITの分岐モデルは非常に強力で、ブランチの作成、切り替え、削除の速度と効率性で知られています。 Gitは、分岐が多いワークフローを積極的に促進します。

個々の開発者は分岐慣行に自由がありますが、チームワークには共有戦略が必要です。 Gitはツールを提供します。チームは最適な使用法を定義します。この記事では、さまざまな分岐戦略、ブランチタイプ、およびGit FlowとGithub Flowの2つの人気のあるワークフローを調査します。

高度なGitシリーズ：

1. パート1： Gitで完璧なコミットを作成します
2. パート2： Gitの分岐戦略（あなたはここにいます！ ）
3. パート3：プルリクエストとのより良いコラボレーション
4. パート4：競合をマージします
5. パート5：リベースvs.マージ
6. パート6：インタラクティブなリベース
7. パート7： GitでCherry-Pickingがコミットします
8. パート8：リフェログを使用して失われたコミットを回復します

チームワーク：分岐条約を確立します

効果的なチームコラボレーションには、文書化された分岐戦略とワークフローが必要です。このドキュメントは、競合を防ぎ、オンボーディングを合理化し、誰もがプロセスを理解するようにします。

慣習の例：

• master （またはmain ）：現在の公開リリース。
• next ：今後の公開リリース（無関係な変更を統合せずにmasterのホットフィックスを許可します）。
• feature/ ：機能ブランチ（このプレフィックスの下に編成）。
• wip/ ：進行中のブランチ（個人的なバックアップ用）。

これらの慣習は説明的です。チームは彼らのニーズに合わせて適応する場合があります。

変更とリリースの構造化の統合

分岐戦略は、変更の統合と解放構造を検討する必要があります。 2つの対照的なアプローチが可能性のスペクトルを強調しています。

• メインライン開発：単一のブランチを使用した「常に統合」アプローチ。すべての貢献はメインラインに直接コミットしています。これにより、追跡が簡素化されますが、厳密なテストと小規模で頻繁なコミットが必要です。

• 状態、リリース、および機能ブランチ：複数のブランチタイプを使用して、機能、リリース、および開発状態を管理します。このアプローチはより複雑ですが、より大きなプロジェクトとチームのためのより良い組織と制御を提供します。ほとんどのチームは、これらの極端な間のどこかに落ちます。

これらをより詳細に調べてみましょう。

メインライン開発

コア原則は継続的な統合です。すべての開発者は、単一のブランチに直接コミットします。これにより、追跡が簡素化されますが、統合の問題を防ぐために高品質のテストが必要です。シンプルさは、堅牢なテストインフラストラクチャを欠いているチームに適さないものになります。

状態、リリース、および機能ブランチ

この戦略は、特徴開発、リリース管理、さまざまな開発段階を表すという、異なる目的でさまざまな分岐タイプを使用します。最初は複雑に見えますが、練習で管理しやすくなり、より複雑なリリースサイクルを持つプロジェクトに適しています。

次に、長期にわたる短命の枝を掘り下げます。

長期にわたる枝

すべてのリポジトリには、 masterまたはmain名前の少なくとも1つがあります。他の長期にわたるブランチには、リリースプロセスのさまざまな段階を表すdevelop 、 production 、またはstagingが含まれる場合があります。これらのブランチは、プロジェクトのライフサイクル全体に続きます。

一般的なルールは、長期にわたる支店への直接コミットを避けることです。代わりに、変更はマージまたはリベッシングによって統合され、コードの品質と制御リリースが確保されます。

短命の枝

これらのブランチは、特定のタスク（新機能、バグ修正、リファクタリング）のために作成され、長期にわたるブランチへの統合後に削除された一時的な目的を果たします。彼らは通常、長期にわたる支店から分岐し、孤立した開発を可能にし、完成した作業をメインラインに戻します。

Git FlowとGithub Flowの2つの一般的な分岐戦略

広く使用されている2つの戦略は、さまざまなアプローチを提供します。

gitフロー

この戦略は、生産リリースにmainを使用し、継続的な開発にdevelop 。開発の分岐ブランチのdevelopとリリースブランチは、リリースの準備のためにdevelopから作成されます。テストすると、リリースブランチがmainにマージされ、タグ付けされ、削除されます。パッケージ化されたソフトウェアには効果的ですが、Webプロジェクトには過度に複雑になる可能性があります。

GitHubフロー

頻繁にリリースする継続的な配信に適したGithub Flowは、単一のmainブランチを使用します。すべての作業は、タイプ（機能、バグ修正、リファクタリング）に関係なく、 mainに統合されるまで独自のブランチに存在します。そのシンプルさは、迅速な反復に最適です。

適切な戦略を選択します

最適な分岐戦略は、コンテキストに依存しています。チームは、プロジェクトのニーズ、リリース戦略、開発プロセスを協力して、最も適切なアプローチを選択する必要があります。万能のソリューションはありません。高度なGitツールをより深く理解するために、「Advanced Git Kit」などの追加リソースを探索することを検討してください。

高度なGitシリーズ：

1. パート1： Gitで完璧なコミットを作成します
2. パート2： Gitの分岐戦略（あなたはここにいます！ ）
3. パート3：プルリクエストとのより良いコラボレーション
4. パート4：競合をマージします
5. パート5：リベースvs.マージ
6. パート6：インタラクティブなリベース
7. パート7： GitでCherry-Pickingがコミットします
8. パート8：リフェログを使用して失われたコミットを回復します

以上がGitの分岐戦略の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。