Mercurial のスカッシュコミット

最近、Mercurialでいくつかのコミットをスカッシュする作業を少し行っていたので、他の人が同じことをしようとしている場合に備えて、投稿する価値があると思いました。これが最良の手順かどうかはわかりませんが、私には非常にうまく機能しているようでした。

hg clone base working
# tip of base is revision 73
cd working
# do work, committing on the way
cd ..
hg clone working squash
cd squash
hg qimport -r 74:tip
hg qgoto 74.diff
hg qfold $(hg qunapp)
hg qfinish -a
cd ../base
hg pull ../squash

私が行っていた基本的な作業は、ファイルとフォルダーをかなり大幅に移動することでした。作業中にチェックポイントを作成するために、これをいくつかの手順で行いたかったのですが、バージョン履歴には1つのコミットだけを残したかったのです。（gitではrebaseでこれがより簡単にできるようです。）単一のコミットを作成すると、何が起こったかを理解しやすくなります。特に、ファイルの移動はリポジトリログの確認を複雑にする傾向があるためです。ファイルの移動もプロセスを複雑にします。何度か、移動を追跡する機能を失ったために機能しない手順になってしまいました。hg log -fを実行して、移動前の元のコミットがいつ、何であったかを確認できるようにしたいのです。

まず、mq拡張機能（Mercurialキュー）を有効にし、diffをgitスタイルに設定する必要がありました。gitスタイルのdiffは、ファイルの移動を適切に追跡するのに役立ちます。

# in ~/.hgrc
[extensions]
mq=

[diff]
git=true 

このようにMercurialを使用する場合、一般的な作業方法は複数のリポジトリを持つことのようです。Mercurialは、他のシステム（例：gitやsvn）が異なるブランチを使用するような、異なるリポジトリを推奨しています。人々はこのことについて議論しますが、これはMercurialの作業方法です。この例では、元のレポとして「base」を使用しました。

最初の手順は、baseをワーキングレポにクローンすることでした。

hg clone base working

この時点で、base（およびworking）の先端はリビジョン73でした。ファイルの移動を行い、途中でいくつかのチェックポイントリビジョンを作成しました。

cd working
hg mv foo1 newdir/foo1
.. more hg mv ..
hg ci -m "moving around"
.. more hg mv ..
hg ci -m "moving around"
.. more hg mv and hg ci..
cd ..

完了するまでに、最後のリビジョンは80でした。

それらを1つのコミットにまとめるために、別のレポをクローンしました。

hg clone working squash

この時点でクローンを作成することが重要です。履歴を編集しようとしていたので、それが機能したことがわかるまで、元の履歴を手元に置いておきたかったからです。そして、そこへ移動しました。

cd squash

次に、リビジョンに対して行ったすべてのコミットを、Mercurialパッチキューメカニズムのパッチに変換しました。

hg qimport -r 74:tip

最初の変更を現在のパッチにしました。

hg qgoto 74.diff

すべてのパッチを1つのパッチにまとめました。

hg qfold $(hg qunapp)

この折りたたまれたパッチのコミットメッセージは、すべての個々のコミットメッセージがリンクされたものになります。クリーンなコミットのために、単一のメッセージが必要でした。

hg qrefresh -m "reorganized files"

次に、パッチを通常のコミットに変換しました。

hg qfinish -a

これで、すべての作業を含む単一のコミットができました。すべてが正常であることを確認するために、特に、移動されたファイルでhg log -fをテストして、履歴がまだそこにあることを確認しました。すべてがうまくいったと確信したら、単一のチェンジセットをベースレポにプルしました。

 
cd ../base
hg pull ../squash
  

バージョン管理システムへの注目が、長年にわたってどのように変化してきたかを見るのは興味深いことです。初期の頃は、主な目的は監査、つまり古いリビジョンに安全に戻ることができることでした。主に問題を診断するためです。その後、人々の共同作業をどのように可能にするかに注目が移りました。これは監査の必要性を置き換えるものではなく、それに基づいて構築されたものです。現在、コードベースの変更履歴を説明するためにそれらを使用することに、より注目が集まっています。そのため、このような履歴書き換えコマンドが必要になっています。これも他の2つのニーズの上に構築されていますが、新しい機能と新しい緊張をもたらします。

同僚のChris Turnerの助けに感謝します。また、このページも非常に役に立ちました。