14年前のCVSリポジトリ（履歴はそのまま）をMercurialに移行することを検討しています。私はすべての技術変換ビットを下げたと思いますが、私は水銀で効果的に働くことについていくつかの質問があります。
個人開発者のcvsサンドボックス（自分のものも含む）でよく目にすることの1つは、メインラインにプッシュする準備ができていないローカルのコミットされていない変更です。これは悪いことだと私は理解しています。hgを使った私の実験のほとんどは、コミットされていない変更は悪いことだと示唆しています。それらとマージできないことで十分です。だから私が知りたいのは、日々のコーディングで水銀を使用する他の人々がそれをどのように扱うかです。リポジトリを更新するときにコードの不完全な変更にどのように対処しますか？（まだ）他の開発者と共有したくないローカルな変更にどのように対処しますか？
回答:
いくつか追加します。
1つは、TortoiseHgに標準で付属しているシェルブを適切に使用するワークフローを提案することです。
現在の作業ディレクトリの一部をコミットしたいときはいつでも、コミットしたくない変更を保留し、再コンパイルして（コンパイルが壊れるビットを保留していないことを確認するため）、テストを実行します。 。それから、私は完全な、動作し、テストされたセットをコミットします。最後にunshelveを実行して変更を復元しました。
もっと永続的な変更がある場合、開発マシンの構成ファイルが常に本番サーバーではなくlocalhostポート3333を指すようにしたい場合、MercurialとTortoiseHgの両方に同梱されているMercurial Queues拡張機能の使用を検討します。。
コミットされていない変更が本質的に悪いことだとは思いません。あなたは「それらとマージできないこと」を参照します-一部のファイルへのコミットされていない変更があり、そのファイルへの変更をプルして更新すると、Mercurialはコミットしたかのようにマージプロセスを開始し、マージ。違う意味ですか？
したがって、他の開発者とまだ共有したくないローカルな変更については、2つのアプローチがあります。1つ目は、変更を作業コピーに保存し、変更をプッシュしないことです。もう1つは、作業コピーの外に置いておきます。どちらを選択するかは、作業中にこれらの変更を利用できるようにするかどうかによって異なります。
作業コピーにそれらを保持する場合、着信変更は正常に機能するため、発信変更の作成を回避するだけで済みます。つまり、変更のコミットを回避できます。ファイルが新しい場合、それは簡単です-しないでhg addください。それらがすでに追跡されている場合、具体的にはを使用してコミットから除外できますhg commit --exclude foo.txt。除外するファイルの数が多い場合、または多くのコミットからそれらを除外する場合（たとえば、ローカル構成ファイルへの永続的な変更のため）、exclude拡張機能を確認します。
変更を移動する準備ができている場合は、別のオプションセットがあります。最も簡単なのはhg diff、ファイルを使用して、ファイルを説明するパッチを作成し、安全な場所に保管して、hg patch --no-commit変更を元に戻したいときにそのパッチを再適用することです。棚の拡張機能、屋根裏部屋の拡張機能、またはその他の親戚をインストールすることにより、これをよりスムーズにすることができます。キュー拡張機能を使用することもできますが、それは大ハンマーを使用してナットをクラックすることです。変更をコミットしてから、親に更新して他の作業をコミットし、変更を不安定な匿名ブランチに残すhg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')こともできます（ただし、手動で行う方が簡単な場合もあります）。ただし、そのチェンジセットをプッシュしないように注意する必要があります。
開発の流れを分離するために2つの基本的なアプローチが使用されます。
名前付きブランチ。自分のブランチであるnmichaels_branch_of_awesomeで作業するという考え方です。そうすれば、他の人の作業を気にせずに変更をコミットできます。次に、必要なときに他の人からマージし、機能の時間になると、より安定したブランチにプッシュして統合します。私は名前付きブランチを支持します。
匿名のクローン。これにより、サンドボックス用に別のリポジトリが作成されます。ここであなたはあなたが望むものを手に入れるまで遊んで、それから（おそらく）あなたのコミットのためにMQパッチを行い、あなたが最初から始めました。私はこのアプローチがあまり好きではありません。ディレクトリ管理が必要であり、MQの作業が必要になる可能性があるためです。そして、いくつかのリポジトリを使用すると、彼らはこのために少しだけ大きくなり始めることができます。とはいえ、これはKiln開発者に好まれるようです。