はじめに
Gitの運用方法といえばの2つのワークフローを理解するために他サイトを参考にまとめてみました。
git flow
git flowと言えばこの図をよくみます。
A successful Git branching model » nvie.com
master
常にリリース可能な状態
develop
開発中のブランチ
feature
機能を開発したりバグ修正などを行う
developから分岐したブランチになる
developにマージする
release
リリース用に準備を行う
developから分岐したブランチになる
developとmasterにマージする
機能開発したfeatureブランチをいきなりdevelopにマージするのではなく、releaseブランチを経由する
hotfix
緊急時の修正作業を行う
masterから分岐したブランチになる
developとmasterにマージする
メリット
- Windowsアプリケーションなどのようにリリース作業に数日かかる開発に適している。
- ブランチごとの役割がはっきりしているためブランチの運用ミスを減らせる。
デメリット
- デプロイ作業が煩雑になる。
github flow
GitHubの開発で使用されており、git flowを簡略にしたワークフローです。
master
常にデプロイ可能な状態
feature
機能を開発したりバグ修正したり、緊急時の対応をしたりする。
masterから分岐したブランチになる
masterにマージする
git flowのようにブランチが目的ごとに分かれていません。
そのため、基本原則に従って、開発を進めます。
- masterブランチは 常時デプロイ可能 である
- 機能追加、バグフィックスなどは 説明的な名前のブランチ をmasterから作成する
* 機能追加の例： add_user_notice (ユーザーの通知機能追加)
* バグフィックスの例： fix_user_login_validation_error (ユーザーのログイン認証のVlidation修正) - 作成したブランチでローカル開発。小さい単位でこまめにコミットし、リモートにもこまめにPush
- フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 Pull Request を作成する
- フィードバックや助言が欲しい時に作成する Pull Request を WIP Pull Request という
- WIP = Work In Progress
- WIP Pull Request を行う場合は、Pull Request 名の頭に [WIP] をつけるのが慣習
- レビューOKになったら、masterへマージ
- masterへpushしたら、即デプロイをする
メリット
- Wedアプリケーションなどのように1日に数回デプロイを行う開発に適している。
- git flowより理解しやすい。
デメリット
- 機能開発や緊急時の修正などブランチが分かれていないため運用ミスが発生する可能性がある。
参考文献
A successful Git branching model » nvie.com
GitHub Flow 図解 - Qiita
GitFlow vs GithubFlow - Qiita
git flowとgithub flowとは？その違いは？ - Qiita
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう：こっそり始めるGit／GitHub超入門（終） - ＠IT