一般的なシナリオ: コントリビューターは、1 つまたは 2 つの有用な変更と、 IDEによって自動的に行われた大量の (私が望まない) 空白の変更を含むプル リクエストを送信します。
もちろん、IDE を調整し、コミットする前に GitX などのツールを使用して特定の変更をステージングするように彼に言うことはできますが、損害は発生します。彼が再コミットしてプッシュを強制する必要があるか、私がすべての変更を受け入れる必要があるか、またはマージする前に「元に戻す」コミットを追加する必要があります。
もっと簡単な方法はありますか？
理想的には、GitX のコミット プロセスと同じようにマージできます。ブランチから特定の変更をステージング解除でき、ツールはコミットを自動書き換えするか、マージ前に「元に戻す」コミットを行います。
空白の変更をローカルで取り除くと、開発者は、承認しなかったすべての空白の変更を自分のバージョンに対する変更として見ることができます。惨めさが広がるだけ。
唯一の解決策は、 1 つの空白スタイルに同意することです (おそらく、ツールによって強制されるか、コミットする前に外部ツールによって行われます)。すべてに均一に。
個人的には、寄稿者に変更を加えて再コミットし、変更を強制的にプッシュするように伝えます。寄稿者はおそらくあなたのリポジトリのフォーク (「オリジン」) で機能ブランチに取り組んでいるため、誰も彼のコミットをフォローしていません。寄稿者が誰もフォローしていないブランチの履歴を書き換えても、実際の損害はありません。変更を取り込んだ後に削除される可能性があります。さらに言えば、寄稿者は最終的なマージを持つ新しい機能ブランチを作成することもできます-可能な変更を行い、新しいプル リクエストを作成し、古いブランチとプル リクエストを削除します (履歴の書き換えがないように)。