5

git やその他の DVCS のコミットをどのようにスカッシュするかについて、(あまりにも) 多くの質問があります。

私の質問は、コミットをスカッシュしたいですか? 機能がどのように開発されたかを示すコミットの詳細なシーケンスを保持する必要がありますか? それとも、機能が完成したら履歴をきれいに保つためにそれらを 1 つにまとめるべきですか?

4

3 に答える 3

8

コミットをスカッシュする理由:

  • よりクリーンでシンプルな歴史。
  • 小さな歴史。リポジトリを複製するときの荷物が少なくなります。
  • タイプミスの修正など、「ジャンク」コミットを削除します。
  • コミット メッセージを改善する機会を提供します。

コミットをスカッシュしない理由:

  • その機能/バグ修正の履歴をたどって、それがどのように開発されたかを調べたり、試行されたが後で置き換えられた代替ソリューションを確認したりすることはできなくなりました. (Mike Gerwitz のA Git Horror Storyから引用。)
  • git bisect が役に立たなくなります。300 の圧縮されたコミットで構成される単一のパッチによって導入されたソフトウェアのバグを見つけた場合、Git に問題を解決してもらうのではなく、コードを掘り下げて自分でデバッグする必要があります。(Mike Gerwitz のA Git Horror Storyから引用。)

独自の回答をしたくない場合は、このウィキの回答に他の理由を自由に追加してください。

于 2013-01-31T12:44:16.550 に答える
1

DVCS の強みの 1 つは、必ずしも公開する必要なく、頻繁に小さなコミットを実行してチェックポイントを設定し、作業を保存できることです。

そうは言っても、私は最近、Mercurial が推奨するデフォルトの「履歴の書き換えは悪い」という立場の制限と思われるものに遭遇し始めました。機能が多くのコミットに分割され、リベースではなくマージされるため、履歴が非常に急速に混乱する可能性があります。DavidMが指摘しているように、どのアプローチ、またはアプローチの組み合わせを採用するかは、その後の履歴の使用方法によって異なります。履歴をよりクリーンに保つために、Mercurial キューやリベースなどのツールをより頻繁に使用していることに気付きました。

また、Mercurial の (現在の)最先端の陳腐化マーカー コンセプトの可能性にも興味をそそられます。元の変更セットを保存し、それらを押しつぶされた変更セットで置き換えることができるようにすることで、ケーキを手に入れて食べることもできるように思われます: デフォルトで表示される最新の適切なサイズの変更セットのみを使用して履歴を消去します-ただし、常にオプションを使用します機能をアンパックし、それに費やされた小さな努力を精査する。

于 2013-02-20T22:51:51.127 に答える