102

コミットされていない変更がたくさんあり、代わりに別の作業をしている間にそれを脇に置きたい場合は、後で (数日後に fi) 戻って作業を続けます。これを達成するための最も簡単なワークフローは何ですか? (これまでのところ、Mercurial の基本機能の経験しかありません)。私の通常の方法は、クローンを使用して新しいブランチを作成することでしたが、もっと良い方法があるかもしれません.

4

4 に答える 4

138

いくつかのオプションがあります:

  1. アイテムを棚上げします。これにより、変更が保存され、作業ディレクトリから削除されるため、ブランチを続行できます。変更セットは作成されません。

    hg shelve --all --name "UnfinishedChanges"

hg unshelve --name "UnfinishedChanges"

    更新/編集: Mercurial の新しいバージョンを使用する必要がある場合があります

    hg shelve -n "UnfinishedChanges"
hg unshelve "UnfinishedChanges"

    --nameの代替として引き続き使用できますが、mercurial はもう-n好きではないようです。--nameさらに、--allはもはや必要ではなく、mercurial は実際にそれを気にするでしょう。

  2. を使用してアイテムをキューにパッチmqします。これはいくつかの点で棚上げするほど似ていませんが、動作が異なります。最終結果は同じで、変更は削除され、必要に応じて後で再適用できます。プッシュされると、パッチは論理的な変更セットになり、ポップされると別の場所に保存され、変更セット履歴の一部にはなりません。

    hg qnew "UnfinishedWork"
hg qrefresh
hg qpop

hg qpush "UnfinishedWork"

  3. それらをローカルにコミットし、以前の変更セットに更新して作業を続行し、匿名ブランチ (または複数のヘッド) を利用します。その後、変更が必要な場合は、ヘッドをマージできます。変更が必要ない場合は、変更セットを削除できます。

    hg commit -m"Commiting unfinished work in-line."
hg update -r<previous revision>

hg strip -r<revision of temporary commit>

  4. それらを名前付きブランチにコミットします。その後、ワークフローはオプション 3 と同じになります。準備ができたらマージまたはストリップします。

    hg branch "NewBranch"
hg commit -m"Commiting unfinished work to temporary named branch."
hg update <previous branch name>

個人的には、オプション 3 または 4 を使用します。これは、変更セットを削除したり、部分的なコードをチェックインしたりすることを気にしないためです (最終的にプッシュされない限り)。これは、必要に応じてローカルの変更セットを他のユーザーから隠すために、新しいフェーズのものと組み合わせて使用​​ できます。

また、コマンドを使用してrebase変更セットを移動し、マージによってコードの履歴に何も追加されないマージを回避します。マージは、重要なブランチ (リリース ブランチなど) 間のアクティビティ、またはより長期間有効な機能ブランチからのアクティビティのために保存する傾向があります。histedit変更セットの「おしゃべり」が値を減らすために使用するコマンドもあります。

パッチ キューもこれを行うための一般的なメカニズムですが、スタック セマンティクスがあります。パッチをプッシュしてポップしますが、スタック内の別のパッチの「下」にあるパッチは、その上にあるパッチもプッシュする必要があります。

警告、これらすべてのオプションと同様に、シェルブ/キュー/ブランチした一時的な変更以降にファイルにさらに変更がある場合は、シェルブ解除/プッシュ/マージ時にマージ解決が必要になります。

于 2012-07-17T09:57:05.457 に答える
23

個人的には、これまでに投稿された回答はどれも好きではありません。

  1. 各プロジェクトにはディレクトリが1 つしかないのが好きなので、クローン ブランチは好きではありません。同時に異なるディレクトリで作業すると、エディターの最近のファイルの履歴が完全に台無しになります。私はいつも間違ったファイルを変更してしまいます。だから私はもうそれをしません。
  2. 私shelveは簡単な修正に使用します（コミットされていない変更を別のブランチに移動するだけです。間違ったブランチにいることに気付いた場合）。あなたは何日も話している、私は何日も何かを棚上げするつもりはない
  3. mqこのような通常の状況では複雑すぎると思います

これらの変更を開始してそこから作業する前に変更セットに戻るよりも、単に変更をコミットするのが最善の方法だと思います。いくつかの小さな問題があります。説明させてください。

変更セット A があるとしましょう。変更を開始するよりも。この時点で、しばらく脇に置いておきます。まず、作業をコミットします。

hg ci -m "Working on new stuff"

必要に応じて、ブックマークを追加して、後で簡単にアクセスできるようにすることができます。私はいつも、匿名ブランチへのブックマークを作成しています。

hg bookmark new-stuff

これらの変更前の変更セットに戻る

hg update A

ここから、変更セット C を作成して生成します。これで 2 つのヘッド (B と C) ができたので、プッシュしようとすると警告が表示されます。ブランチのヘッドを指定することで、1 つのブランチのみをプッシュできます。

hg push -r C

new-stuffまたは、ブランチのフェーズをシークレットに変更できます。秘密の変更セットはプッシュされません。

hg phase -r new-stuff --secret --force
于 2012-07-25T18:09:35.293 に答える
13

ローカルのコミットされていない変更を保持するには、パッチ ファイルとして保存するのが最も簡単な方法です。

hg diff > /tmp/`hg id -i`.patch

前の状態に戻す必要がある場合:

hg up <REV_WHERE_SAVED>
hg patch --no-commit /tmp/<REV_WHERE_SAVED>.patch
于 2014-06-20T16:04:07.273 に答える
6

レポを複数回複製できます。私はルートクローンを作成し、そこから複数の子を作成する傾向があります。例：

  • MyProject.Root
  • MyProject.BugFix1
  • MyProject.BugFix2
  • MyProject.FeatureChange1
  • MyProject.FeatureChange2

4 つの子はすべてルートから複製され、ルートとの間でプッシュ/プルされます。次に、ルートは、ネットワーク/インターネットのどこかにあるマスター リポジトリからプッシュ/プルします。ルートは、一種の個人的なステージング エリアとして機能します。

したがって、あなたの場合、新しいレポを複製して作業を開始するだけです。「棚上げ」された作業は、他のレポにそのままにしておきます。それはとても簡単です。

唯一の欠点はディスク容量の使用ですが、それが懸念される場合は、とにかく DVCS を使用していないでしょう ;) ああ、それは Visual Studio の「最近のプロジェクト」リストを汚染しますが、なんと.

[次のコメントを編集] :-

結論として、あなたがしていることはまったく問題なく正常です。私は、次のことが当てはまる場合、これが最善の作業方法であると主張します: 1) 短命である 2) 他の開発者と協力する必要がない 3) 変更がコミットされるまで PC から離れる必要がない/プッシュタイム。

于 2012-07-17T10:24:48.317 に答える