6

コミットしたくないファイルで作業している場合は、それらを保存します。次に、サーバーにプッシュしたい他のファイルがありますが、他の誰かがリポジトリに変更を加えた場合、それらをプルダウンすると、マージまたはリベースするように求められます..しかし、これらのオプションのいずれかにより、私のコミットしていないローカルの変更。

これを回避するために他の人は何をしていますか？シェルビング エクステンションのドキュメントを理解するのは難しいと思います。

注: Mercurial Eclipse を使用して、サーバーとの間でファイルをプッシュおよびプルしています。

これについての説明は大歓迎です！ありがとう！

例：

Mercurial Eclipse で自分の Web サイトに取り組んでいます。まだサーバーにコミットしたくない新しいフォルダーと新しいファイルがあります。また、いくつかの既存のファイルを変更しましたが、それらの変更をまだ公開したくありません。

次に、Web サイトの何かが壊れて修正する必要があります。リベースまたはレポの最新のヒントとマージしないと修正できません。これにより、コミットされていない変更がすべて失われます。

編集した新しいフォルダとファイルを失いたくない場合、どうすればよいですか? 再クローニングは面倒に思えます。ファイルを新しいフォルダにコピーするのも面倒です。Shelving や MQ が私のやりたいことをやってくれると確信していますが、どうすればいいのかまだわかりません。

4

2 に答える 2

4

あなたの例の状況を参照して、私がやることは次のとおりです(Ry4anの戦略に従って、現在取り組んでいることをコミットするだけで、まだ公開したくない):

次のようなリポジトリで作業を開始するとします。

$ hg status -A
C f1
C f2
$ hg glog
@  changeset:   1:7f3c6c86a92f
|  tag:         tip
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

つまり、2 つのファイルと 2 つのコミット/変更セットがあります。いくつかの作業を行い、たとえば新しい機能を追加すると、作業コピーは次のようになります。

$ hg status
M f2
? f3
? f4

2 つの新しいファイルと 1 つの変更されたファイルがあります。ここで、バグを修正する必要があります。そのために、リモート リポジトリに新しい変更も必要です。現在の作業をコミットしてスナップショットを作成し、リモートの変更をプルします (実行する順序は重要ではありません。デフォルトでは、プルは作業コピーの状態には影響しません)。

$ hg commit -A -m "snapshot feature work"
$ hg pull

これにより、次のような履歴が表示される場合があります。

o  changeset:   3:2284ba62de07            <-- just pulled in
|  tag:         tip
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| @  changeset:   2:4a19d371a04f          <-- your interrupted work
|/   summary:     snapshot feature work
|
o  changeset:   1:7f3c6c86a92f
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

これで、リビジョン 3 に更新/チェックアウトして、バグの修正を開始できます。

$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
@  changeset:   4:5d3d947fb4af
|  tag:         tip
|  summary:     fix a bug
|
o  changeset:   3:2284ba62de07
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| o  changeset:   2:4a19d371a04f
|/   summary:     snapshot feature work
:

よさそうです。中間作業を公開せずに、修正をプッシュしましょう。つまり、ライブにしましょう。

$ hg push -r 4

これにより、リビジョン 4、バグ修正につながるすべての変更がプッシュされますが、ローカル リポジトリには他のブランチはプッシュされません。-r .作業コピーの親リビジョン、つまりコミットしたばかりのリビジョンを参照する を使用することもできます。

最後に、機能の作業に戻って作業を続けることができます。

$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4

これらの手順はコマンド ライン上にありますが、一般的な概念を Eclipse Mercurial プラグインの対応するクリックに適応させることは難しくないと思います。

いくつかの追加メモ:

  • リビジョン ID や番号を操作する必要がないように、スナップショット コミットをブックマークすることもできます。
  • 機能の作業を後で 1 回のコミットで公開したい場合は、完了したら折りたたみ拡張機能を使用してください。
于 2011-06-19T20:29:13.947 に答える
2

誰かが悪い回避策を見つけるのを手伝ってくれると確信していますが、最善の方法は目標を変更することです-ただコミットしてください. コミットされていないコードは書かれていません。履歴に頻繁にコミットすることが絶対に許せない場合は、キュー リポジトリで Mercurial キューを使用し、それをコミットします。その後、変更セットをポップし、プッシュ/プル/マージし、それらをプッシュして戻すことができます。貴重な作業はすべてパッチ キューにコミットされます。

于 2011-06-18T02:47:23.427 に答える