ブランチでコミットを (git rebase -i を使用して) スカッシュすると、スカッシュされたコミットが新しいコミットではなく古いコミットと結合されることにいつも悩まされます。
なぜこのように設計されたのか理解できません。進行中の作業 (WIP) をコミットすると、それはコンパイルされていないコードまたは完成していないコードを表します。やっとコミットしたら「やっと動く！」マージする前に commit と squash を行う必要があるため、これらの WIP コミットを組み合わせて「やっと動く!」以前のコミットと結合されるのではなく、コミットします。WIP を押しつぶすと、基本的に、コンパイルできないことがわかっているコードで以前のコミットが「中断」されます。
これを回避するために、私のワークフローは、「それは機能します!」からコミットを押しつぶすことです。最初の WIP コミットの前にさかのぼります。しかし、これはばかげていませんか？WIP を以前のコミットに押しつぶすことが理にかなっている他の人々は何をしていますか?
次に、 を使用して最初の WIPgit reset --softにリセットHEAD(および のみHEAD) し、そこから (最新で最終的に機能する WIP のインデックスと作業ツリーを使用して) コミットしないでください。
そうすれば、それらのコミットをまとめてすばやく押しつぶすことができます。
詳細については、「最近の X コミットを git を使用してまとめてつぶすにはどうすればよいですか?」を参照してください。
これは、「 ?の実用的な使用法git reset --soft」に関する私の結論を反映しています。
毎回：
- 最終的に得られるものに満足している（作業ツリーとインデックスに関して）
- そこにたどり着くまでのすべてのコミットに満足していない:
git reset --softが答えです。
最新のコミットを古いものに押しつぶすと、両方の差分が保持されます。古いコミットを「選択」しているからといって、進行中のコミットのバグを修正する新しい作業が除外されるわけではありません。
を使用してみてくださいgit rebase -i HEAD~4。ただし、4 を、おそらく作業状態である HEAD から始めて、結合したいコミットの数に置き換えます。
http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.htmlには、インタラクティブなリベースの使用に関する優れたガイドがあります。