理解してみる

GitLab Flowとは

production、pre-production、main、featureからなるブランチ戦略である
主なブランチは「main」で、機能ブランチをマージし、必要に応じてプレプロダクションやプロダクションブランチを使用

引用：GitLab flow とは

開発の進め方

ブランチ作成
mainブランチからfeature/NAMEブランチを作成
開発とマージリクエスト
開発完了後、mainブランチへマージリクエストを作成
ステージング環境デプロイ
mainブランチをステージング環境にデプロイし動作確認
本番前準備
mainからpre-productionへマージリクエストを作成しテスト
本番リリース
pre-productionからproductionへマージリクエストを作成しデプロイ

ベストプラクティス

featureブランチの使用
- すべての新しい作業（機能追加やバグ修正）に機能ブランチを作成し、mainブランチをクリーンに保つ
mainブランチのプロダクション対応
- mainブランチは常にプロダクションにデプロイ可能な状態を保つ
マージリクエストの必須化
- すべての変更はマージリクエストを通じてmainに統合される
必須のコードレビュー
- すべてのマージリクエストは少なくとも1人のチームメンバーによるレビューを受け、コード品質を維持する
自動テストの実施
- GitLabのCI/CDパイプラインを使用して、機能ブランチとmainブランチで自動テストを実行する
短期間の機能ブランチ
- 機能ブランチは短期間で作成・マージし、mainブランチとのコンフリクトを最小限に抑える
明確なブランチ命名
- ブランチ名に一貫した命名規則を採用し、例えばfeature/123-login-fixのようにする
issueとのリンク
- マージリクエストを対応するissueにリンクし、開発進捗を追跡可能にする
プレプロダクションブランチの活用
- 必要に応じてプレプロダクションブランチ（例：test、acceptance）を追加し、mainからのマージでテストを行う
ホットフィックスの管理
- 緊急のバグ修正にはmainからホットフィックスブランチを作成し、修正後すぐにmainにマージする

Githubでの実践に向けて

導入したものがあれば追記予定

設定した方が良いこと

ブランチ保護ルールの設定
- プルリクエストレビューを必須化
- すべてのチェックが通過することを必須化
- フォースプッシュとブランチ削除を防止
- プルリクエストの承認数を指定
Github Actionsを使ってCI/CDを組む
明確な記述とレビュアーの割り当て
- プルリクエストには詳細な説明を書き、特定のレビュアーを割り当てます。レビュアーはコードコメントや議論を通じてフィードバック1. 議論の解決
- すべての議論が解決されるまでプルリクエストをマージしないようにする
PR-Agnetを使ったAIコードレビュー
- PR-AgentとBedrockでGitHubのPRをAIにレビューしてもらう
- PR-Agent を使って Pull Request をAIレビューしてみた。（日本語対応もしてみた）
- pr-agentを入れてみるテスト