[B! git-flow] T-miuraのブックマーク

T-miura id:T-miura

git-flowに関するT-miuraのブックマーク (2)

俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景一昨年末くらいにgit-flowを採用していた良いんだけど、結構めんどくさいなーと思うところがあった去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗るただ本番をそれで運用するわけにもいかないリリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点気に入っている点並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利めんどくさい所 releaseブランチ毎回作る必要性をあまり感じないバー
T-miura 2014/04/17
git-flow

git

バージョン管理

development

workflow
リンク
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
T-miura 2014/03/26
Jenkins

heroku

git-flow

開発フロー
リンク
1