(小さい) チームのためのフレキシブルな Git の workflow

git

以下エントリをネタ集めのために要約してみます。

  • A Flexible Git Workflow For Teams.
  • ここでも master branch を中心に、という考えになっています
    • 最早このアイデアが現在の主流ですね
  • feature branch は小さく
  • review は Github の Pull Request で master との差分の確認
    • review された branch は問題なければ LGTM (Looks Good To Me) なコメントが投入される
  • Squash Merging て何だろ
    • PR なソレは git rebase -i で纏めて云々、という事か
    • merge されたら feature branch は廃棄
  • feature が大規模なんですが問題にどう対処するか
    • rollout て何でしょ
    • 開発してる人にはその巨大な feature が見えて user には見えない?
  • Git Reflow というツールを云々なさっている模様

む

rollout の自己紹介エントリみたいの発見。

ええと、redis て何だったか。

むむ

redis て KVS とのことだけどもしかして

  • stable なソレはどこかの commit で止めた状態
  • 開発なナニは上記の形で育てる

という状態を Feature Flipper で操作、という事なのかな。これ、どこかで試してみたいですね。

とは言え

やはり、でっかい feature をどう扱うのか、は色々な意味で課題なのかどうか。