0

重複の可能性:
Mercurial の紹介

私の最近の変更はリモートです。私は最終的にこれを正しく行いましたか？

$ hg pull
warning: code.google.com certificate with fingerprint d2:33:75:af:62:64:5b:75:dc:3f:bf:22:30:b6:27:13:ff:3f:90:fd not verified (check hostfingerprints or web.cacerts config setting)
pulling from https://niklasro@code.google.com/p/montao/
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
ubuntu@ubuntu:/media/Lexar/montao$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

では、マージを行うべきではなく、プルを行うべきですか?

2 人の開発者が協力する簡単な例がないのはなぜですか?

例えば

Time        Developer 1              Developer  2
              hg clone                 hg clone
              editing
              hg commit
              hg push
                                       editing
                                       hg pull
                                       hg commit
                                       hg push

上記のような 2 人の開発者間のワークフローの例は、hg プル、マージ、更新が何であるかを理解しやすくし、プルとマージを混同しないようにします。

たとえば、別の場所からの変更セットがあるときに 2 つのヘッドを取得しない方法を知っています。

2 人の開発者がどのように協力し、どのようにリモートで変更を取得するかの例が必要になる場合があります。

4

3 に答える 3

5

基本概念

プルは、他の開発者からの新しいチェンジセットを独自のリポジトリにもたらします。これは潜在的に新しい頭を導入する可能性があります、もしそうならそう言うでしょう。

マージは2つのヘッドを1つに結合します。ヘッドが1つ以下の場合は、マージする必要はありません。

Updateは、リビジョンを切り替えます。たとえば、現在の作業リビジョンからプルしたばかりのリビジョンに切り替えます。ローカルのコミットされていない変更がある場合、updateは追跡されていないマージを実行してそれらを結合しようとします。

プル後に更新するかマージするかは、プルによって新しいヘッドが導入されたかどうかによって異なります。

シンプルな2人の開発者のワークフロー

2人の開発者間で直接協力する場合の最も単純な基本ワークフローは次のとおりです。

  1. hg pull otherdev
  2. hg updateまたhg merge
  3. 編集
  4. hg commit -m "testing..."

プル+更新（省略形:)pull -uは、コードの最新バージョンから始めていることを確認します。同僚が最後のプルとコミットの間に変更を加えた場合、これにより、新しいヘッドが導入されたため、代わりにマージする必要があることがわかります。

常にプルする必要はありません。時々スキップして、しばらくの間、編集、コミット、編集、コミット（...）することもできます。何かに取り組んでいて、フローを中断したくない場合は、準備ができるまでプルとマージを待ってください（ただし、少なくとも1日に1回は実行します）。

一般に、変更を同僚にプッシュするべきではありません。このようにして、リポジトリにあるものをそれぞれ制御し続けることができ、突然表示される新しいチェンジセットに混乱することはありません。

注：ステップ3と4の間で更新することにより、分岐するブランチを作成する可能性を減らすことができます。SVNでは、これは強制的に行われることです。ただし、競合がある場合は変更が壊れた状態のままになり、修正するまでコミットできないため、この方法はお勧めしません。DVCSの大きな利点の1つは、これを回避し、マージに煩わされる前に作業コードを安全にコミットできることです。

改善された2人の開発者のワークフロー

このワークフローを改善するために、実際には、お互いから直接プルするのではなく、あなたとあなたの同僚が中間として使用するための3番目の共有リポジトリを作成することをお勧めします。

これにより追加の手順が導入されpushますが、これの良い点は、プッシュすることで、一連のコミットを作成し、変更を同僚と共有する準備ができたときに自分で決定できることです。これにより、テストに必要な時間が短縮され、同僚が誤って何かを壊して引き込んだために同僚の時間を無駄にする可能性が低くなります。

于 2011-10-25T11:11:10.490 に答える
1

入力するとhg help pull

それが示している：

pull changes from the specified source

    Pull changes from a remote repository to a local one.

つまり、RemoteRepository->Local Repository 操作です。ローカルの作業ディレクトリとは関係ありません。

「hg help merge」と入力すると

merge working directory with another revision

    The current working directory is updated with all changes made in the requested revision since the last common predecessor revision.

これは、ローカル リポジトリとローカルの作業コピーの間で発生します。リモートリポジトリとは関係ありません。

例/マニュアルを求めた場合、ネット上にたくさんあります。ここにいくつかリストします。お役に立てば幸いです。

http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://www.rutherfurd.net/2010/apr/22/merging-mercurial-example/
https ://www.mercurial-scm.org/wiki/TutorialMerge

于 2011-10-25T10:59:17.917 に答える
1

Mercurial と他のいくつかの VCS の使用方法の詳細な例については、Eric Sink のVersion Control by Exampleまたは Joel Spolsky のhginit.comを参照してください (Joel を 2 番目にリストすると、私の回答は自動的に反対票を投じられますか?)

于 2011-10-25T12:01:08.890 に答える