2

Mercurial の基本を理解しようとしているので、ご容赦ください。:) 私の現在のワークフローは次のとおりです。

  • コミットする準備が整うまで、または他の人の変更が必要になるまで、いくつかの作業を行います
  • 引く
  • この時点で、自分の作業を最新の変更セットとマージしてコミットしたいのですが、Mercurial はマージする前にコミットすることを主張しています。
  • つまり、「コミット、マージ、コミット」のようになり、基本的にすべてを2回コミットし、両方の変更セットに同じメモを書き、一度に2つの変更セットをプッシュします

そうなることを意図しているのでしょうか？マージごとに変更セットを 1 つだけ取得することは可能ですか? それは本当に望ましいことですか？

多くのオンライン マニュアルを読みましたが、まだプロセスを十分に理解していないと感じています。すべてのコメントを歓迎します。ありがとう！

編集:更新が受信した変更をコミットされていない編集とマージできることを知りませんでした。

4

3 に答える 3

3

マージすると、常に Mercurial に別の変更セットが作成されます。

さらに、ローカル リポジトリにコミットされていないものがある限り、マージはできません。
したがって、解決策は、最初にコミットし、後でプルしてマージすることです。
これにより、1 つではなく、常に2 つのチェンジセットが作成されます。
(...マージすると常に別の変更セットが作成されるため)

しかし、同じものを 2 回コミットすることはありません。特に、同じコミット メッセージを 2 回書くべきではありません。

最初のコミットは、実際に変更したものです (「foo バーのバグを修正しました」)。
2 番目のコミットは単なるマージです (TortoiseHG は実際にコミット メッセージに "Merge" を事前入力します。99% の時間はそのままにしておきます)。

于 2012-08-28T20:55:08.887 に答える
2

このワークフローは履歴のマージを防ぎますが、以下に示すようにマージを実行します。

  • コミットする準備が整うまで、または別の変更が必要になるまで、いくつかの作業を行います。
  • hg pull
  • hg update(注:hg pull -uこれと前のステップを 1 つのステップで実行します。

の間hg update、コミットされていない変更は現在のブランチの新しいヒントにマージされます。競合がある場合は、引き続き解決する必要があります。

  • hg commit準備ができたら。

マージがうまくいかない場合は、その変更セットに更新することで最初からやり直す方が簡単なので、プル/マージする前に最初にコミットする広範な変更がある場合でもお勧めします。

hg pullと を分離しておくとhg update、入ってくる変更セットを見て、マージがどのように進むかを予測できます。

于 2012-08-29T01:20:50.770 に答える
1

奇妙に感じる理由は、他の人と統合するまでコミットを遅らせることです。

分散バージョン管理の大きな特徴は、コミットがローカルであることです。それらはローカルであるため、頻繁にコミットする必要があります。小さな一貫した作業のチャンクが完了するたびにコミットしてください。あなたのコミットはすぐに他の人に影響を与えるわけではないので、多くの小さなコミットを行ってコミットを中断することはありません。

さらにコミットを開始すると、ワークフローが次のようになることがわかります。

$ hg commit -m "Refactoring for Issue123"
$ hg commit -m "Basic functionality for Issue123"
$ hg commit -m "Fixed off-by-one error (Issue123)"
$ hg commit -m "Finished implementing Issue123"
$ hg commit -m "Added more tests for Issue123"
$ hg commit -m "Begin use new function from Issue123"
$ hg pull
$ hg merge
$ hg commit -m "Merge"

ここで、「実際の」コミットに対するマージ コミットの比率は、はるかに賢明です。

多くの人 (私自身を含む) は、マージを完全に回避するためにrebase 拡張機能を使用することを好みます。その拡張機能は、履歴を偽造することでコミットを線形化するため、 でプルダウンした変更セットの後に4 つのコミットを行ったように見えますhg pull。ワークフローの唯一の変更点は、上記hg rebaseの代わりにhg merge、最終コミットをスキップすることです。

于 2012-08-29T08:32:10.257 に答える