翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Gitflow 戦略のブランチ
Gitflow 分岐戦略には通常、次のブランチがあります。
機能ブランチ
Feature ブランチは、機能を開発する短期ブランチです。feature ブランチは、developブランチから分岐することによって作成されます。デベロッパーは、featureブランチでコードを反復、コミット、テストします。機能が完了すると、デベロッパーは機能を昇格させます。特徴量ブランチから転送されるパスは 2 つだけです。
-
sandboxブランチにマージする -
developブランチへのマージリクエストを作成する
命名規則: |
|
命名規則の例: |
|
サンドボックスブランチ
sandbox ブランチは、Gitflow の非標準の短期ブランチです。ただし、CI/CD パイプラインの開発に役立ちます。sandbox ブランチは主に以下の目的で使用されます。
-
手動デプロイではなく CI/CD パイプラインを使用して、サンドボックス環境への完全なデプロイを実行します。
-
開発やテストなど、より低い環境で完全なテストのマージリクエストを送信する前に、パイプラインを開発してテストします。
Sandbox ブランチは本質的に一時的なものであり、存続期間が長いものではありません。これらは、特定のテストが完了した後に削除する必要があります。
命名規則: |
|
命名規則の例: |
|
ブランチの開発
develop ブランチは、機能が統合、構築、検証され、開発環境にデプロイされる存続期間の長いブランチです。すべてのfeatureブランチがdevelopブランチにマージされます。develop ブランチへのマージは、ビルドの成功と 2 つのデベロッパーの承認を必要とするマージリクエストを通じて完了します。削除を防ぐには、ブランチでdevelopブランチ保護を有効にします。
命名規則: |
|
リリースブランチ
Gitflow では、releaseブランチは短期ブランチです。これらのブランチは、ビルドワンス、デプロイ、または多くの方法論を取り入れて、複数の環境にデプロイできるため、特別なブランチです。 Releaseブランチは、テスト、ステージング、または本番環境をターゲットにできます。開発チームがより高い環境に機能を昇格することを決定したら、新しいreleaseブランチを作成し、以前のリリースのバージョン番号をインクリメントします。各環境のゲートでは、デプロイを続行するには手動承認が必要です。 Releaseブランチでは、マージリクエストを変更する必要があります。
release ブランチが本番環境にデプロイされたら、 developブランチと mainブランチにマージして、バグ修正や修正が将来の開発作業にマージされるようにする必要があります。
命名規則: |
|
命名規則の例: |
|
メインブランチ
main ブランチは存続期間の長いブランチで、常に本番環境で実行されているコードを表します。リリースパイプラインからのデプロイが成功すると、コードはリリースブランチからブランチmainに自動的にマージされます。削除を防ぐには、ブランチでmainブランチ保護を有効にします。
命名規則: |
|
バグ修正ブランチ
bugfix ブランチは、本番環境にリリースされていないリリースブランチの問題を修正するために使用される短期ブランチです。bugfix ブランチは、releaseブランチ内の修正をテスト、ステージング、または本番環境に昇格させる場合にのみ使用してください。bugfix ブランチは常にブランチからrelease分岐されます。
バグ修正がテストされたら、マージリクエストを通じてreleaseブランチに昇格できます。その後、標準のリリースプロセスに従ってreleaseブランチをプッシュできます。
命名規則: |
|
命名規則の例: |
|
修正ブランチ
hotfix ブランチは、本番環境の問題を修正するために使用される短期的なブランチです。これは、本番環境に到達するために迅速化する必要がある修正を昇格させる場合にのみ使用されます。hotfix ブランチは常に から分岐されますmain。
修正がテストされたら、 から作成されたreleaseブランチへのマージリクエストを通じて、修正を本番環境に昇格させることができますmain。テストでは、標準のリリースプロセスに従ってreleaseブランチをプッシュできます。
命名規則: |
|
命名規則の例: |
|