mcaz
9/16/2019 - 5:37 PM
Git: Terminal: Command: BranchModel: DesignPattern
git-flow (A succeful Git branching model)
Vincent Driessenが考案
Flow
メインブランチ
ブランチの中でも常に存在しており、開発の中心になる中核のブランチのこと。チームメンバーが最も参照するブランチ。開発中のすべての昨日は、いずれメインブランチに取り込まれる。
- masterブランチ
- developブランチ
サポートブランチ
メインブランチから派生し、役目を終えると再びメインブランチに吸収されるブランチ
- featureブランチ
- releaseブランチ
- hotfixブランチ
masterブランチ
- ブランチ名：master
- マージ先：梨
- 他のブランチからのマージ：featureブランチ・releaseブランチ・hotfixブランチ
リリース可能な状態のソフトウェアを常に維持するブランチ。 リリース可能とはソフトウェアが安定的に動作できる状態を保っている状態。 コードレビューされていない、結合されていないコードがmasterへマージされるのは避ける必要がある。 実際にリリースする内容までを含むのがmasterブランチであり、作りかけの昨日は入れない。 masterブランチへの直接のコミットは避け、他のブランチからのマージによって更新していく。 リリース済みの昨日だけが入っているので、リリース後に問題が見つかった場合の修正の起点にもなるブランチ。
developブランチ
- ブランチ名：develop
- 派生元：master
- マージ先：なし
- 他のブランチからのマージ：feature・release・hotfix
最新の開発の状態を反映するブランチ。チームメンバーが機能単位のブランチから機能を足していくブランチになるので、 日々機能がたされていき、チームでの最新の成果物が見られるブランチ。 初期にmasterから分岐していこう、ずっとmasterと並行して開発が進み、直接developとmasterでマージを行うことはない。 開発用ブランチのため、チーム全員が参照することになる。そのため、派生ブランチを作成したチームメンバーが ビルドやテスト進行を妨げられないように動作の安定性が求められる。 developに取り込まれるコードはレビューや単体テストをクリアしている必要がある。 基本的に直接コミットすることはない。
featureブランチ
- ブランチ名：feature-*と名付けることが多いがルールはない
- 派生元：develop
- マージ先：develop
新機能を開発する際に使用。 機能単位ごとにteatureブランチを作成される。機能単位ごとに作成されるのでブランチなので、 リリース予定やマイルストーンにない機能に関するfeatureブランチは存在しないことになる。 たいてい少人数で参照される。開発内容は開発集雨量段階で メインブランチへのマージ前コードレビュー・機能レビューが行われチームメンバーに把握される。 機能テスト・レビュー後にdevelopブランチへマージする。 マージ後に削除する。
releaseブランチ
- ブランチ名の慣習：release-*
- 派生元：develop
- マージ先：メインブランチ(master, develop)
GitHub flow (A succeful Git branching model)
GitHubが提唱したブランチモデル、GitHub本社でも実践されている。 git-flowをよりWeb開発に適した形に変更したブランチ運用パターン。
Links
Flow
特徴
- masterブランチとfeatureブランチの2種類のみで運用する。
- masterブランチはいつでもデプロイ可能な状態になっている
- 新たな開發を行う際は、masterからブランチを新規にチェックアウトして行う。新規ブランチ名は名前だけで概要がわかる明確なものにする(例：new-oath2-scopes)
- 自分の開發ブランチをマージしたい際は、GitHub上でプルリクを行う。作りかけでもレビューやヘルプを頼む際にもプルリクを作る。
- masterにマージできるのはプルリク上でマージされたブランチのみ
- 開發ブランチがmasterにマージされたら、速やかにmasterをデプロイする。
ブランチ
- master
- 製品出荷ブランチ。いつでもデプロイ可能であり、本番環境へのリリースは唯一このブランチから
- feature
- 開發を行うためのブランチ
開発フロー
- masterブランチからfeatrueブランチをチェックアウト
- featureブランチで開発
- 開発が終わった、レビューをしてほしい場合はmasterブランチに向けてfeatureブランチのプルリクを作成
- レビュー
- レビュー完了後にプルリクをマージ
- featureブランチがマージされたmasterブランチを速やかに本番環境へデプロイ
運用に適したプロジェクトの条件
- 高頻度でリリースが可能な業務要件で有ること
- 開発したコードは完成後すぐにデプロイできる環境である必要があるリリースの前準備にテストなどに時間を費やすようなソフトウェア開発には向かない。審査が必要なiOSアポ売や、出荷前に数多くのテストを必要とするミッションクリティカルなソフトウェアなど
- 出荷する製品が最新のバージョンただ1つのみであること
- Webサービスの開発に合わせてmasterブランチ1つで製品の出荷を管理しているため、バージョン別リリースのように複数の製品ラインを持つソフトウェア開発には向かない
- masterブランチを速やかにデプロイできるリリースシステム
- 速やかなデプロイのためにはリリースシステムの充実も必須。プルリクがmasterにマージされたのを検知して、自動的に本番環境をリリースするようなシステムが必要。