MergeCat: CIがgreenになったらPull-Requestをマージ
GitHubを使ってPull-Request駆動で開発していると、CIに待たされることがよくあります。 レビューは一瞬で通る軽微な変更をPull-Requestにした時マージする前にrebaseしてコミットを整理した時リリースの為にdevelopからmasterへのPull-Requestをした時このようなケースでは、CIが通り次第Pull-Requestをマージしたいでしょう。そんな時に人間がCIが通るのを待つのは時間の無駄です。5分、10分かかるテストをただ待っていても何も良いことはありません。 かと言ってPull-Requestを放置していると、そのPull-Requestの存在を人間は忘れてしまいます。運が良ければ1時間後にそのPull-Requestの存在を思い出して、マージできるかもしれません。運が悪いとPull-Requestが他の変更とコンフリクトして、もう一度CIを待つハ
レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita
こんにちは、freee でエンジニアをしている @nasa4w です。 この記事は freee Engineers Advent Calendar の10日目です。 今回は大きな機能を複数のPRに分割する話をします。 freeeでも絶賛模索中の取り組みなので現在進行形の話ですm(_ _)m まとめ - 今回作ったブランチとPR - 長くなってしまったので結論をさきに置いておきます。PRを複数に分割する場合のゴールはこんな感じ。 Why?（なぜこうしたか） こうすることで、常に work ブランチを使って動作確認ができる レビューする PR を２つに分割できる view の PR と logic の PR レビュー指摘の反映は、topic_view, topic_logic ブランチに commit すればOK work ブランチにはこの2つのブランチを merge しなおすだけでOK PR
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
