翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Gitflow 分岐戦略
Gitflow は、複数のブランチを使用して開発から本番環境にコードを移動する分岐モデルです。Gitflow は、リリースサイクルがスケジュールされており、機能のコレクションをリリースとして定義する必要があるチームに適しています。開発は、個々の機能ブランチで完了し、承認されて開発ブランチにマージされ、統合に使用されます。このブランチの機能は、本番稼働準備ができていると見なされます。計画されたすべての機能が開発ブランチに蓄積されると、上位環境にデプロイするためのリリースブランチが作成されます。この分離により、定義されたスケジュールで名前付き環境に移行する変更の制御が向上します。必要に応じて、このプロセスを高速なデプロイモデルに高速化できます。
Gitflow 分岐戦略の詳細については、次のリソースを参照してください。
+ [マルチアカウント DevOps 環境の Gitflow 分岐戦略を実装する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (AWS 規範ガイダンス)
+ [元の Gitflow ブログ](https://nvie.com/posts/a-successful-git-branching-model/) (Vincent Driessen 氏のブログ記事)
+ [Gitflow ワークフロー](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian)
**Topics**
+ [Gitflow 戦略の視覚的な概要](visual-overview-of-the-gitflow-strategy.md)
+ [Gitflow 戦略のブランチ](branches-in-a-gitflow-strategy.md)
+ [Gitflow 戦略の利点と欠点](advantages-and-disadvantages-of-the-gitflow-strategy.md)
# Gitflow 戦略の視覚的な概要
次の図は、Gitflow 分岐戦略を理解するために [Punnett の四角](https://en.wikipedia.org/wiki/Punnett_square)形のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。円で囲まれた数字は、図に示されている一連のアクションをガイドします。各環境で発生するアクティビティの詳細については、このガイドの[DevOps 環境](understanding-the-devops-environments.md)」を参照してください。
![\[各ブランチと環境の Gitflow アクティビティの Punnett 二乗\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png)
# Gitflow 戦略のブランチ
Gitflow 分岐戦略には通常、次のブランチがあります。
![\[Gitflow 分岐戦略のブランチと環境。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)
## 機能ブランチ
`Feature` ブランチは、機能を開発する短期ブランチです。`feature` ブランチは、`develop`ブランチから分岐することによって作成されます。開発者は、`feature`ブランチでコードを反復、コミット、テストします。機能が完了すると、開発者は機能を昇格させます。特徴量ブランチから転送されるパスは 2 つだけです。
+ `sandbox` ブランチにマージする
+ `develop` ブランチへのマージリクエストを作成する
| | |
| --- |--- |
| 命名規則: | `feature/__` |
| 命名規則の例: | `feature/123456_MS_Implement_Feature_A` |
## サンドボックスブランチ
`sandbox` ブランチは、Gitflow の非標準短期ブランチです。ただし、CI/CD パイプラインの開発に役立ちます。`sandbox` ブランチは主に以下の目的に使用されます。
+ 手動デプロイではなく CI/CD パイプラインを使用して、サンドボックス環境への完全なデプロイを実行します。
+ 開発やテストなど、より低い環境で完全なテストのためのマージリクエストを送信する前に、パイプラインを開発してテストします。
`Sandbox` ブランチは一時的なものであり、存続期間が長いものではありません。これらは、特定のテストが完了した後に削除する必要があります。
| | |
| --- |--- |
| 命名規則: | `sandbox/__` |
| 命名規則の例: | `sandbox/123456_MS_Test_Pipeline_Deploy` |
## ブランチの開発
`develop` ブランチは、機能が統合、構築、検証され、開発環境にデプロイされる存続期間の長いブランチです。すべての`feature`ブランチが`develop`ブランチにマージされます。`develop` ブランチへのマージは、ビルドの成功と 2 つの開発者の承認を必要とするマージリクエストを通じて完了します。削除を防ぐには、ブランチで`develop`ブランチ保護を有効にします。
| | |
| --- |--- |
| 命名規則: | `develop` |
## リリースブランチ
Gitflow では、`release`ブランチは短期ブランチです。これらのブランチは、ビルドオンワンのデプロイ多の方法論を取り入れて、複数の環境にデプロイできるため、特別なブランチです。 `Release`ブランチは、テスト環境、ステージング環境、または本番環境をターゲットにできます。開発チームがより高い環境に機能を昇格することを決定したら、新しい`release`ブランチを作成し、以前のリリースのバージョン番号をインクリメントします。各環境のゲートでは、デプロイを続行するには手動承認が必要です。 `Release`ブランチでは、マージリクエストを変更する必要があります。
`release` ブランチが本番環境にデプロイされたら、 `develop`ブランチと `main`ブランチにマージして、バグ修正やホットフィックスが将来の開発作業にマージされるようにする必要があります。
| | |
| --- |--- |
| 命名規則: | `release/v{major}.{minor}` |
| 命名規則の例: | `release/v1.0` |
## メインブランチ
`main` ブランチは、本番環境で実行されているコードを常に表す存続期間の長いブランチです。リリースパイプラインからのデプロイが成功すると、コードはリリースブランチから`main`ブランチに自動的にマージされます。削除を防ぐには、ブランチで`main`ブランチ保護を有効にします。
| | |
| --- |--- |
| 命名規則: | `main` |
## バグ修正ブランチ
`bugfix` ブランチは、本番環境にリリースされていないリリースブランチの問題を修正するために使用される短期ブランチです。`bugfix` ブランチは、`release`ブランチ内の修正をテスト、ステージング、または本番環境に昇格させる場合にのみ使用してください。`bugfix` ブランチは常に`release`ブランチから分岐されます。
バグ修正がテストされたら、マージリクエストを通じて`release`ブランチに昇格できます。その後、標準のリリースプロセスに従って`release`ブランチをプッシュできます。
| | |
| --- |--- |
| 命名規則: | `bugfix/__` |
| 命名規則の例: | `bugfix/123456_MS_Fix_Problem_A` |
## 修正ブランチ
`hotfix` ブランチは、本番環境の問題を修正するために使用される短期ブランチです。これは、本番環境に到達するために迅速化する必要がある修正を昇格させるためにのみ使用されます。`hotfix` ブランチは常に からブランチされます`main`。
ホットフィックスがテストされたら、 から作成された`release`ブランチへのマージリクエストを通じて本番環境に昇格できます`main`。テストでは、標準のリリースプロセスに従って`release`ブランチをプッシュできます。
| | |
| --- |--- |
| 命名規則: | `hotfix/__` |
| 命名規則の例: | `hotfix/123456_MS_Fix_Problem_A` |
# Gitflow 戦略の利点と欠点
Gitflow 分岐戦略は、リリースとコンプライアンスの要件が厳しい大規模で分散されたチームに適しています。Gitflow は組織の予測可能なリリースサイクルに貢献します。これは多くの場合、大規模な組織で推奨されます。Gitflow は、ソフトウェア開発のライフサイクルを適切に完了するためにガードレールを必要とするチームにも適しています。これは、レビューと品質保証の機会が戦略に組み込まれているためです。Gitflow は、複数のバージョンの本番リリースを同時に維持する必要があるチームにも適しています。GItflow の欠点は、他の分岐モデルよりも複雑であり、正常に完了するにはパターンに厳密に準拠する必要があることです。Gitflow は、リリースブランチを管理するという厳格な性質のため、継続的デリバリーを目指す組織ではうまく機能しません。Gitflow リリースブランチは存続期間の長いブランチであり、タイムリーに適切に対処しないと技術的負債が蓄積される可能性があります。
## 利点
Gitflow ベースの開発には、開発プロセスを改善し、コラボレーションを合理化し、ソフトウェアの全体的な品質を向上させることができるいくつかの利点があります。以下は、主な利点の一部です。
+ **予測可能なリリースプロセス** – Gitflow は、定期的かつ予測可能なリリースプロセスに従います。これは、定期的に開発とリリースを行うチームに適しています。
+ **コラボレーションの向上** – Gitflow は、 ブランチ`feature`と `release`ブランチの使用を推奨します。これらの 2 つのブランチは、チームが相互に最小限の依存関係で並行して作業するのに役立ちます。
+ **複数の環境に最適** – Gitflow は、存続期間の長い`release`ブランチであるブランチを使用します。これらのブランチにより、チームは個々のリリースを長期間にわたってターゲットにすることができます。
+ **本番環境の複数のバージョン** – チームが本番環境のソフトウェアの複数のバージョンをサポートしている場合、Gitflow `release`ブランチはこの要件をサポートします。
+ **組み込みコード品質レビュー** – Gitflow は、コードが別の環境に昇格する前に、コードレビューと承認の使用を要求し、推奨します。このプロセスは、すべてのコードプロモーションにこのステップを要求することで、開発者間の摩擦を排除します。
+ **組織のメリット** – Gitflow は組織レベルでもメリットがあります。Gitflow は、組織がリリーススケジュールを理解し、予測するのに役立つ標準リリースサイクルの使用を推奨します。ビジネスは新機能をいつ配信できるかを理解しているため、配信日が設定されているため、タイムラインの摩擦が軽減されます。
## 欠点
Gitflow ベースの開発には、開発プロセスとチームダイナミクスに影響を与える可能性のある欠点がいくつかあります。以下は、いくつかの注目すべき欠点です。
+ **複雑さ** – Gitflow は新しいチームが学習するための複雑なパターンであり、これを正常に使用するには Gitflow のルールに従う必要があります。
+ **継続的デプロイ** – Gitflow は、多くのデプロイが迅速に本番環境にリリースされるモデルには適していません。これは、Gitflow が複数のブランチを使用し、`release`ブランチを管理する厳格なワークフローを必要とするためです。
+ **ブランチ管理** – Gitflow は多くのブランチを使用するため、維持に負担がかかる場合があります。ブランチを互いに適切に整列させるために、さまざまなブランチを追跡し、リリースされたコードをマージするのは難しい場合があります。
+ **技術的負債** – Gitflow リリースは通常、他の分岐モデルよりも遅いため、リリースのためにより多くの機能が蓄積され、技術的負債が蓄積される可能性があります。
チームは、Gitflow ベースの開発がプロジェクトに適したアプローチかどうかを判断する際に、これらの欠点を慎重に検討する必要があります。