私たちのチームは、メインブランチにマージされる前に各機能ブランチコードをレビューするという共通のPR戦略を採用しました。また、ブランチが完了したときに大きな矛盾を避けるために、メインブランチで頻繁にマージするという戦略を採用しました。コードMaster Mergesでプルリクエストを確認する
これはうまくいっていますが、ビルドに時間がかかるという問題があります。私はビルドに数週間かかったブランチを見直すコードを見ています。 PRには100以上のファイルが100以上もコミットされています。さて、実際の機能はおそらくそれらの約15％に過ぎず、残りはメインブランチとのマージです。
これを縮小して、このブランチの新しいコードだけに焦点を当てる方法はありますか？実際にコードレビューされてメインブランチにマージされた100行のコードを調べる必要はありませんか？
この場合の提案は、rebaseです。あなたは、あなたのフィーチャーブランチがマスターブランチと時代遅れになっているかもしれないオープンソースのリポジトリーでこれが求められることがよくあります。
ブランチヒストリを巻き戻し、再配置する現在のブランチの先端に設定してから、ユニークな変更を再度適用して、すべてが最新であることを意味します。
注意：マージ競合は、機能ブランチの成熟度によってさまざまな段階で競合を修正する必要があるため、長期実行ブランチを混乱させる可能性があります。
メインブランチをフィーチャーブランチにマージして、変更内容をに適用して、の変更を適用することもできます。私はこのアプローチが気に入らないのは、あなたの変更が無関係なコードの下であなたのフィーチャに埋もれているからです。しかし、あなたが行ったときにあなたのコードが「完成」状態にあるので、この方法で競合を修正する方が簡単です。
featurebranchベースではなく、マージされた最後のマスターコミットである将来のマージのマージベースと比較します。この方法では、機能ブランチで何が行われたかだけを確認できます。
あなたはgit diff master...featureを呼び出すことで、コミットを探しせずにそれを行うことができます