はじめに
ここで紹介するGit運用方法は、あくまで私が実際に運用して管理しやすいと思ったものです。
また、今回は「小規模案件で運用するにあたって」という観点でご紹介いたします。
最適解かどうかはご自分で判断いただき、部分的に参考になったところを取り入れるなどしていただけたら幸いです。
各ブランチについて
master：
大元。一番上の親となるブランチ。
本番環境のリソースはこのブランチのリソースと一致する。
develop：
開発用ブランチ。featureブランチはすべてここにマージされる。
このブランチは複数切らず、案件開始時に一回のみ切るブランチ。
feature：
各機能ごとに作るブランチ。
よくfutureと間違えて「フューチャー」と読む方がいるが、正しい読み方は「フィーチャー」。
複数切るブランチになるのため「feature/機能名」のようにする。
release：
リリース用ブランチ。段階リリースを行う場合に作成するブランチ。
複数切るブランチになるため「release/リリース日」のようにする。
hotfix：
バグ修正用ブランチ。バグ修正が必要になった場合に一時的に作成するブランチ。
複数切るブランチになるため「hotfix/バグ名」のようにする。
主に上記5種類のブランチがありますが、実際にプログラムの実装やディレクトリ構造の変更などを行うブランチは「feature」と「hotfix」のみとなります。
実際の運用手順
「ブランチ」という言葉だらけになってしまうので、以下「ブランチ」は省略します。
- masterからdevelopを切る。
- masterからreleaseを切る。
- developからfeatureを切る。（機能ごとにブランチを切るので、複数のfeatureを切ることがほとんど）
- feature内で作業し、変更内容をdevelopにマージ。
- 全てのfeatureをdevelopにマージできたら、developをreleaseにマージ。
- releaseを本番環境にデプロイして、問題が無ければreleaseをmasterにマージ。
- masterをdevelopにマージ。
- 本番運用中にバグが発生した場合は、masterからhotfixを切る。
- hotfixでバグ修正を行い、hotfixをデプロイ。
- 問題なければhotfixをmasterにマージ。
- masterをdevelopにマージ。
- 次のリリースに向けてmasterからreleaseを切る。
- 以降、3番の手順に戻って繰り返し。
上記手順を分かりやすく下記の図にまとめました。
まとめ
今回紹介した内容はあくまで一例です。releaseブランチが無い方がうまくいったり、developブランチが複数あった方が良かったり、hotfixが一度に複数ある場合は新しくreleaseを切ってまとめるなど、案件の規模や参画人数などによって一番良い運用を行いましょう。
