はじめに
GitHubを使用したソースコード管理の基本を紹介します。
1. mainブランチ
本番環境用の安定版コードを保持
mainブランチは常に安定した状態で保つ必要があります。
本番環境で稼働しているコードは、常にこのブランチに含まれており、リリース済みのコードが管理されています。
通常、mainブランチへの変更は、リリースが完了した後に行います。
本番環境で問題が発生した場合、緊急の修正はhotfixブランチで行い、修正後はmainブランチにマージします。
マージ先:
releaseブランチやhotfixブランチで行われた変更は、最終的にmainブランチにマージされます。
2. developブランチ
開発中のコードを集約するためのブランチ
開発中のコードや新しい機能、バグ修正はすべてdevelopブランチに集約されます。
このブランチでは、まだ本番環境にリリースするには不安定な変更が含まれている可能性があります。
developブランチは、最終的に安定した状態でreleaseブランチへ移行し、リリース準備を整えます。
featureブランチやbugfixブランチで行った変更は、まずdevelopにマージされます。
マージ先:
feature、bugfix、releaseブランチからの変更はdevelopブランチにマージされます。
3. featureブランチ
新機能を開発するためのブランチ
新しい機能を開発する際は、developブランチから新しいfeatureブランチを切ります。
各機能は、独立したfeatureブランチで開発され、完成後にdevelopブランチに統合されます。
featureブランチは、特定の機能が完成した段階でマージされるため、個別に管理することで他の作業と干渉することなく進行できます。
マージ先:
開発が完了したfeatureブランチは、developブランチにマージされます。
4. bugfixブランチ
バグ修正を行うためのブランチ
バグ修正用のブランチは、developブランチから派生します。
通常、既存の機能に問題が発生した場合に使われます。
bugfixブランチでは、バグを修正することに集中し、修正が完了したらdevelopブランチにマージします。
bugfixブランチは、緊急の修正が必要でない場合に使用され、通常の開発サイクル内で処理されます。
マージ先:
修正が完了したbugfixブランチは、developブランチにマージされます。
5. releaseブランチ
リリース準備を行うためのブランチ
developブランチで安定した状態になった時点で、リリース準備を行うためにreleaseブランチを作成します。
このブランチでは、リリースに向けた最終調整やバグ修正を行います。
releaseブランチは本番リリース前に行う最後の調整やテストが行われる場所です。
調整が完了したら、最終的にmainブランチにマージし、リリースします。
マージ先:
releaseブランチは、リリース準備が整った後、mainブランチにマージされます。
また、developブランチにも変更が反映されます。
6. hotfixブランチ
本番環境での緊急修正を行うためのブランチ
本番環境で深刻な問題が発生した場合、mainブランチから直接hotfixブランチを作成し、緊急の修正を行います。
修正後は、mainブランチにマージし、問題が解決したことを確認した後、必要に応じてdevelopブランチにも変更を反映させます。
マージ先:
hotfixブランチは、修正が完了した後、mainとdevelopブランチにマージされます。
7. stagingブランチ（オプション）
リリース前の最終確認を行うためのブランチ
stagingブランチは、releaseブランチから分岐し、実際に本番環境にリリースする前に最終確認を行うためのブランチです。
本番環境への影響を最小限に抑えるため、stagingブランチで最終テストを行い、問題がないことを確認した後、mainブランチにマージします。
マージ先:
最終テスト後、stagingブランチはmainブランチにマージされ、リリースが行われます。
まとめ
GitHubを使用したソースコード管理では、適切なブランチ戦略を採用することで、チーム開発の効率が大幅に向上します。
main: 本番用の安定コードを保持
develop: 開発中のコードを集約
feature: 新機能開発
bugfix: バグ修正
release: リリース準備
hotfix: 緊急修正
staging: 最終確認（オプション）
これらのブランチを適切に使い分けることで、開発の透明性を高め、リリースサイクルの安定性を確保できます。