エスケーのGit開発フロー

2012年10月25日

エンジニア勉強会

基本的な方針

  • git-dailyにのっかる
  • MergeRequest(ゆるふわ)
  • デザイナリリース

git-dailyにのっかる

git-daily?

git-daily？

git-daily

ひとことで言うと…

git-flowのWeb開発特化版

git-flow??

git-flow

ひとことで言うと…

A successful Git branching model を補助するGit wrapper tool

Git wrapper tool???

Git wrapper tool

  • Gitラッパツール == サブコマンドとかエイリアスとも言う
  • パスの通ったところに git-* な実行ファイルを設置すれば勝手に認識してくれる

git-daily, git-flow以外にも様々なwrapper toolがある

  • git-ticket
    • Redmineと連携
  • git-hook
    • hookをgistなどから任意のイベントに簡単設定
  • git-now
    • テンポラリのコミットを大量に作成してあとでまとめる手法を補助
  • git-助けて
    • 「git 助けて」で状況にあったコマンドが出てくる
  • git-balse
    • コミットメッセージにバルスが含まれていると可能な限りリポジトリを破壊

で

A successful Git branching model????

A successful Git branching model

ひとことで言うと…

成功したGitのブランチ運用モデル(直訳)

自由すぎるGitのブランチに規則を設けていい感じに開発できるようにする…

ブランチ運用モデル

  • master
    • リリースされている最新のソースコード
  • develop
    • 開発用ブランチ
  • feature/xxxx
    • 特定機能xxx用ブランチ
  • release/yyyy
    • yyyyリリース用ブランチ
  • hotfix/zzzz
    • masterブランチの緊急修正用ブランチ

ただ

git-flowはWeb開発に向いていない

  • リリース頻度が多い
    • リリースにいちいち名前つけてらんない
    • タグいらない
  • リモート連携してくれない
    • ローカルブランチをうまいことやってくれるだけ
    • 共同開発ではリモートのほうもうまくやってほしい

そこで

git-daily

git-dailyの特徴

  • releaseに日付で自動的に名前づけ
  • タグを切らない
  • 適当にリモートと連携

コマンド例

git daily release open
  • release/yyyy-mmdd-hhMMを自動生成
  • ブランチ作成後、リモートにpush

コマンド例

git daily release close
  • リリースブランチをmasterにmerge
  • masterブランチのpush
  • リリースブランチをdeveloopにmerge
  • developブランチのpush
  • remoteのリリースブランチの削除
  • localからも削除

とりあえず

git-dailyは

  • 複雑な手順を簡略化してくれるし
  • リモート側もいい感じに整理してくれるし
  • 色々楽

SKでインスパイヤしたところ

  • developがメイン開発ブランチ
  • 大きな機能を開発するときはfeatureを切る
  • リリース時にはreleaseブランチを切る

以上のルールにのっかりさえしてればOK

あとはリモートとの連携も便利コマンドが全部やってくれるので楽

SKで独自のところ

  • 各自 working/username/develop ブランチを持つ
    • feature切るような機能でもないちょっとした修正
    • ただdevelopにはpushしたくないとき
      • developは基本いつでもrelease可能なものしかない
    • デザインはできたけどJSの振舞を実装してないときとか…

Merge Request

(ゆるふわ)

他の人の担当している部分を修正するときはMerge Requestする

Merge Request?

Merge Request

  • GitLabの機能のひとつ
  • GitHubでいうPull Request
    • ちょっとこの変更とりこんでよ
    • って感じで相手にpullをリクエストする
    • パッチを送るようなもの

GitLab??

GitLab

  • githubのクローン
  • だいたいの機能がそろってる
  • 毎月22日に定期アップデート
    • 現在v3.0.2
    • すさまじい開発速度

で

なんでMerge Request

  • 担当者に対するおうかがい
    • ここ直したけどあってる?
  • コードレビュー
    • コード知識の共有
    • 設計

ただし、ゆるふわ

結構 Merge Request しないときもある

わりと気分

またはお互い実装部分が違いすぎてやる気力と時間がない、とも言う

ゆえに失敗もおこる

結構見落としたままリリースしたり

お互いボーンヘッドしたりしている

GitLabにはForkがない

  • feature/hoge -> feature/hoge にリクエスト不可
  • 必ずブランチを作成する必要がある
  • 共同開発に不便
  • feature/hoge -> working/okada/feature/hogeブランチを作成してそこからMerge Request

デザイナーズリリース

デザイナさんにもGitを押し付け

デプロイ作業も一任

  • samba x Git クライアントで割と使いこなせるっぽい
  • 過去2名はわりと使いこなしている

デプロイ

fabricでコマンド3発

fab release:open
fab production deploy_web_server:apache=reload deploy_media_server
fab release close
  • git release open実行
  • Webサーバとメディアサーバのリポジトリを最新リリースブランチに更新
  • apacheを再起動
  • git release close実行

デプロイ

Web ツール

  • commit / pull / push / release をブラウザで行う
  • みーやんさんとかりょーたさんが主にこちらを利用

まとめ

  • git-dailyとGitLabをメインに利用
    • developがメインブランチ
    • 大きな機能を開発するときはfeatureを切る
    • リリース時にはreleaseブランチを切る
    • 大きな機能でもないときはdevelopに直接マージする
    • 他の人の担当している部分を修正するときはMergeRequest
    • それぞれ working/username/develop を持つ
    • デザイン修正などはデザイナさんが直接リリース

おわり