俺のオレオレ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ブランチ毎回作る必要性をあまり感じない バー
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
