http://togetter.com/li/673629 こういうふうにまとめてくださっていたのですが、自分なりの考えの補足など。 上記でも言及している、「俺のオレオレgit-flow」というエントリにも書きましたが、この運用で進めてみて結構良かったなーと思っている。その辺に関しては以下のツイートしたりした。 masterでQA通してからreleaseブランチにマージしてdeployって感じすなー。 — songmu (@songmu) 2014, 5月 30 ゲームだと画像内の文字の表記間違いとかをやらかすだけで、その事後対応でプログラマの稼働が下手すりゃ一日飛ぶので、master直deployは怖いので、並列でreleaseブランチを走らせて、そっちにマージしつつdeployしてる。 — songmu (@songmu) 2014, 5月 30 masterからreleaseへのマー

発表資料 リポジトリ CPAN 動画 一時間強の長きにわたってお付き合いいただいいた皆様有難うございました。 今回ライブコーディングを引き受けた上で考えたのは以下の点。 いつもの開発っぽい雰囲気ですすめたい ちゃんとテストは書きたい 普段どのように開発しているかの雰囲気と、どういうタイミングでテストを書いているのかとかを、普段テストを書き慣れていない人にもできれば勘所が分かるようにしたいなーとか思っていました。 実際は結構内容を詰め込んでしまって駆け足になってしまったりとか、コンソールでの作業が長かったのでちょっとイメージを掴みづらい人も多かったかもしれないなと反省しています。 最初1時間もらった時は長すぎだと思っていたのですが、実際は全然足りませんでした。あれ以上長くやっても、見ている方もダレると思うので、もっとうまくまとめてできるようになりたい。 またやりたくなった。YAPC::Asi

普段から普通にやっている方法です。 git fetch git checkout -b $BRANCH_NAME origin/master git push -u origin $BRANCH_NAMEgit fetchでoriginを最新にして、origin/masterからブランチを切ります。 これで、プロジェクトの最新の状態からbranchを切る事が出来ます。 現在どのbranchに居るかを気にせずとも、branchを切る元を間違える事がないので安心です。 （例えばうっかり関係ないtopic branchから切ってしまう。といったことを気にしなくて良くなります。） また、git push -u origin $BRANCH_NAMEすることにより、 リモートブランチがupstreamとして紐付く為、いちいちgit pull origin $BRANCH_NAMEとかしなくて良くなり