巨大 Pull Requestを避けるための9つのポイント - Qiita
巨大 Pull Requestの問題 レビューに時間がかかる、疎かになる テストとコードを照らし合わせが大変 本番で問題が起きたときに、問題の切り分けがしにくい masterとの差分を反映する際のレビューが難しくなる 一つのミスが大きなfeatureブランチになるきっかけになることも 大きくなるとmergeに時間がかかり、ますます大きくなる どのようにして大きなPRを避けるか PRが大きくなりそうな時は事前に相談する 作業しているときに、変更点がたくさん必要になったときは早めにレビューアーに相談する 複数人で開発しているときは、しっかり話す時間をとる PRが大きくなる問題は後で変更するのが難しいので、最優先で相談するとよい。近くにいるなら直接相談する。いないときはチャットで相談する。 モデルだけの変更とテストを書く なにか機能の変更がある時に、まずモデルからレビューする 実際にどういう変化
中の人に聞いたGitHub flowの本当の使い方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
