Blog

git flowとgithub flow

2014.01.14Cat:git プログラマー

今回は、gitを使うチーム作業の流れを紹介したいと思います。

git flow

gitを使ってブランチを分けて作業する運用手法です。
feature(機能追加、このブランチは複数ある)、develop、master、release(複数)、hotfix(緊急の修正、masterにマージしたら削除される)という全部5つ種類のブランチを使います。
フローの概要をつかむため、ここをまず見るのをお勧めします。
sourceTreeの機能を利用すると、簡単に実現できるのようです。

基本的な流れ

  1. developをベースに開発用ブランチを作成して(これがfeatureにあたる)開発者それぞれが開発をスタート
  2. 他の人が開発したコードを自分の開発用ブランチにマージ
  3. 開発が終われば編集内容をdevelopにマージして、開発者用ブランチを削除
  4. developブランチをremoteブランチにpush
  5. 4を繰り返して開発を進める
  6. 開発が終了したらリリースのための作業を始める(developをベースにreleaseブランチを利用、 軽微なバグフィックス、リリース向けのコードや設定の編集)
  7. releaseの編集を終えたら、developとmasterに内容をマージして、releaseブランチを削除
  8. リリースを行う(masterブランチのデプロイ)
  9. リリース後に、緊急バグが発生したらmasterをベースにhotfixブランチを作成し、対応
  10. 対応できたらmasterにマージし、hotfixブランチを削除
  11. 10を繰り返してバージョン管理を運用する

参考リンク

git flow cheatsheet(英語)
git flow cheatsheet(日本語訳)
運用事例

github flow

githubを使う運用手法、ではなく、
github開発チーム内部で使っているgit flowをカスタマイズしたものです。
開発の一時ブランチ(複数)と、masterブランチの2種類のブランチのみ使います。

git flowの短所

  • ブランチの切替えはやや複雑
  • 短時間に繰り返すデプロイには不向き

github flowの特徴

  • masterブランチは常にデプロイ可能な状態にしておく
  • 新しい開発などは、masterからブランチを作成して名前をつけ、そこで行う(一時ブランチ)
  • 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
  • フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 pull request を作成する
  • 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる(プレビュー前のマージが発生しない→ルールとして強制)
  • マージをしてmasterへpushしたら、直ちにデプロイをする

参考リンク

github flow(英語)
github flow(日本語訳)

Author Profile

jeff_maj

システムエンジニア/1984年生/上海交通大学卒/Webサービス/EC/iphone/android

» 投稿一覧
  • Launch Cart次世代ECサイト構築システム 初期月額無料
  • LaunchMovie ECに特化した動画制作サービス

Archive

ページTOPへ