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