非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
GitHub Flow – Scott Chacon
Issues with git-flow I travel all over the place teaching Git to people and nearly every class and workshop I’ve done recently has asked me what I think about git-flow. I always answer that I think that it’s great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner.
小規模開発には git-flow よりも GitHub Flow で捗る - TMD45INC!!!
これまで CVS や Subversion ではなかなか敷居の高かった「ブランチを切って作業する」というワークフローが、分散型バージョン管理、とくに Git の登場でとても手軽に取り入れやすくなりました。 Git のブランチを活用するためのワークフローとして有名なものに git-flow と呼ばれているモデルがあります。正しい名称は「A successful Git branching model」で、git-flow はこのモデルの導入を補助してくれる Git 拡張の名称だそうです。 A successful Git branching model（@oshow さんによる日本語訳） git-flow の解説～導入までは以下の記事に詳しく書かれています。 git-flow によるブランチの管理 - O'Reilly Japan Community Blog これはあくまで ”モデル” な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Flow (Japanese translation)
