Для получения подробных примеров того, как использовать Mercurial и несколько других VCS, ознакомьтесь с Управление версиями на примерах Эрика Синка или hginit.com Джоэла Спольски (получает ли мой ответ автоматический отрицательный голос за то, что Джоэл указан вторым?)

Основные понятия

Pull приносит новые наборы изменений от других разработчиков в ваш собственный репозиторий. Потенциально это может ввести новую голову, об этом будет сказано, если это произойдет.

Объединить объединяет две головы в одну. Не нужно объединяться, если голов не больше 1.

Обновление переключает между версиями, например. из вашей текущей рабочей версии в ту, которую вы только что вставили. Если у вас есть локальные незафиксированные изменения, обновление попытается объединить их, выполнив неотслеживаемое слияние.

Будете ли вы обновлять или объединять после извлечения, зависит от того, появились ли в результате извлечения новые головы.

Простой рабочий процесс для двух разработчиков

Самый простой базовый рабочий процесс при непосредственном сотрудничестве между двумя разработчиками:

1. hg pull otherdev
2. hg update or hg merge
3. Редактировать
4. hg commit -m "testing..."

Вытягивание + обновление (сокращенно: pull -u) гарантирует, что вы начинаете с самой последней версии кода. Если ваш коллега внес какие-либо изменения между вашим последним извлечением и фиксацией, это сообщит вам, что он ввел новую голову, и вместо этого вам нужно выполнить слияние.

Вы не всегда должны тянуть, вы также можете иногда пропустить это и просто редактировать, фиксировать, редактировать, фиксировать (...) на некоторое время; если вы над чем-то работаете и не хотите прерывать свой поток, просто подождите с подтягиванием и слиянием, пока не будете готовы (но я бы делал это хотя бы раз в день).

В общем, вы не должны навязывать изменения своему коллеге; таким образом, каждый из вас сохраняет контроль над тем, что находится в вашем репозитории, и вас не смущают внезапно появившиеся новые наборы изменений.

Примечание. Обновляя между шагами 3 и 4, вы снижаете вероятность создания расходящейся ветки, в SVN это то, что вы вынуждены делать. Однако я бы порекомендовал против эту практику, потому что, если есть конфликты, это оставит ваши изменения в неработающем состоянии, и вы не сможете их зафиксировать, пока не исправите. Одним из больших преимуществ DVCS является именно то, что вы можете избежать этого и безопасно зафиксировать свой рабочий код, прежде чем беспокоиться о слиянии.

Улучшенный рабочий процесс для двух разработчиков

Чтобы улучшить этот рабочий процесс, я бы порекомендовал создать третий общий репозиторий для вас и вашего коллеги, чтобы использовать его в качестве промежуточного звена, вместо того, чтобы напрямую получать данные друг от друга.

Это вводит дополнительный шаг push, но приятно то, что вы можете сделать кучу коммитов и решить самостоятельно, когда ваши изменения будут готовы поделиться с вашим коллегой, путем нажатия. Это сокращает время, необходимое для тестирования, и вероятность того, что ваш коллега потратит время впустую, потому что вы случайно что-то сломали, а он это вытащил.

Если вы наберете 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