git flowとgithub flowざっくりまとめ

最近学校のチーム制作で、gitを使うことになったので
前半は復習も兼ねてgitそのものの基礎的なコマンドや参考リンクの紹介

後半はタイトルとおり、注目されているリポジトリモデルである
git flowと、それを簡易的に発展させたgithub flowの簡単な内容を
確認したいと思います。

1.gitの基礎と使い方

参考リンク
* wikipedia git
* Pro git 和訳
* gitを使いこなすために20のコマンド

概要

  1. Linuxの開発者リーナス・トーバルズが開発
  2. 分散型バージョン管理システム(svnは集中型)
  3. ネットワークにつながっていないときでも、ログの確認、コミットが可能
  4. 代表的なweb上のgitホスティングサービスとしてgithub, bitbucket, 国内ならgitbreakなど。

超基本的な使い方

  1. git clone [gitのアドレス] で既存リポジトリを自分の環境にコピー
  2. ソースコードを編集
  3. git statusで変更を確認
  4. git add [ソースコードのパス] でコミットするファイルを明示する
  5. git commit -m ‘コミットコメント’ でaddしたファイルの変更点をローカルリポジトリにコミット
  6. git push [送信先リモートリポジトリ名] [送信先ブランチ名] でリモートリポジトリに変更点を送信
  7. 2-6を繰り返す

これが最低限必要なコマンド(だと思います)
これ以外だと

  • git diff
  • git log
  • git reset
  • git branch
  • git merge
  • git checkout
  • git init

とかが慣れてきてから使えれば、まぁいいと思います。

僕の個人的な意見としては、上記の1-7の流れ程度はコマンドラインから行えることが
最低限だけど、それ以外は各種GUIクライアントを利用したほうが、楽だし効率もいいかな
と思ってます。GUIで確認できるコミットログや、brunchのツリーなんかは
CUIでは体感できないものかな、と思います。

代表的なクライアントにはsmartGitや、sourceTreeなど。
githubも公式でクライアントをリリースしています。

このブログのメインであるgit flowに関しては、このうちsourceTreeのみ
アプリケーション内で、git flowに関する機能を補完してくれる
機能を備えています。
(もちろん補完されないだけで、どのクライアントでもCUIでもgit flowは
使えます。)

2.git-flowとは

参考リンク

概要

ちゃんとした内容は原典や参考リンクを読んでいただければと思いますが
ざっくりと説明すると

  • Gitにおけるリポジトリのモデル(こんなふうにbrunchを切って運用すれば便利じゃね?みたいな感じ)
  • Git flowというコマンドを別途インストールするかsourceTreeの機能を利用すると簡単に実現できる(しなくても運用で実現は可能)
  • Git flowのリポジトリモデルをそのまま用いず、各所でカスタマイズして利用されている(参考リンク参照)
  • メインのmasterブランチ、developブランチを主軸に、feature,release,hotfixの補助的なbrunch群で構成される
  • masterブランチは常にリリースできる状態、開発はdevelpブランチから、更にブランチを作成して行う。(それがfeature,release,hotfix)
  • featureは機能追加のためのブランチ(通常時はこれがメインになるのかな?)
  • releaseはリリース直前のためのブランチ
  • hotfixはリリース直後の緊急対応用のブランチ

こんな感じ

基本的な流れは

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

こんな感じです。developをベースに作成したブランチで基本的に作業を行い、完了したらマージしてブランチ削除、が
基本的な流れです。 developやmasterのコードを直接編集してはいけません。あくまでベースになり、マージ対象になるだけ。

3.github-flowとは

参考リンク

github内(サービスではなくてgithub開発チームの内部、という意味)で運用されている
git-flowをベースにしたリポジトリモデルです。

githubの中の人であるscott chacon氏はgit flowを『I always answer that I think that it’s great
( (git flowについて聞かれたときに)素晴らしいものであると、いつも答えている)』
としながらも、ふたつの短所をあげています。

  1. ほとんどのチームや開発者が実際に必要とするよりも複雑すぎではないか
  2. 1の複雑な操作をGUIツールに操作を強制することができず、
    CUIで全操作を行う必要がある(現在はsource treeがあるので、一応GUIでも操作できるけど)

これをより単純にすることで解決したものが、github flowらしいです。

特徴

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

これだけですね。developブランチという概念がなくなったこと、プルリクエストというgithubの独自機能
が運用に用いられていることが、git flowとの大きな違いです。

僕が思う、github flowのもうひとつのメリットとして

プレビュー前にmasterへのマージが発生しない

ということです。これならだれでも気軽に、開発を行い、プルリクエストをして、上級者からのレビューを受けることが
可能になります。(そうすることが上級者にも強制される)

レビューやテストが重要視される昨今にマッチしたモデルであると個人的には思います。


git flowは各所で賞賛され、利用されているモデルではあるみたいですが、やはり銀の弾丸ではないので、
プロジェクトや企業によって、カスタマイズされている場合も多くあるようです。

ぼくは git flowを知るまでは、ブランチをモデル化して運用する、ということすら
考えがなかったので、とても勉強になりました。

git flowとgithub flowざっくりまとめ」への3件のフィードバック

  1. ピンバック: Githubでプルリクエストとか、ちゃんと覚えようと思う | KentaKomai Blog

  2. ピンバック: GitHub Flowについて調べています | maruTA(Bis5)'s Weblog – Side T:echnology

  3. ピンバック: 20150927 - Git 復習用 - yamablog

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です