Mercurial и Git, как они обрабатывают регистрацию, когда файл был изменен - PullRequest
0 голосов
/ 01 декабря 2011

Представьте, что пользователь # 1 изменяет file1, а пользователь # 2 также изменяет file1. Изменения не требуют слияния вручную.

Пользователь # 1 уже зарегистрировал свои изменения и отправил их в центральное хранилище. Теперь пользователь # 2 хочет запихнуть свои изменения в.

Из того, что я слышал, Mercurial заставит вас обновить локальную копию, прежде чем вы внесете изменения. И из-за этого изменения, которые вы нажимаете, создают впечатление, что вы изменили файлы пользователя # 1, хотя на самом деле это не так.

Это правильно?

Git делает это по-другому?

Ответы [ 3 ]

3 голосов
/ 01 декабря 2011

При работе с главным репозиторием в Mercurial у вас есть два варианта.

Типичный рабочий процесс - слияние. Это означает, что вы фиксируете свои изменения локально, затем вносите изменения второго человека в свой клон, а затем объединяете все изменения в набор изменений слияния. Затем вы можете отправить обе фиксации в главный репозиторий.

отредактировано в соответствии с Мартином:

Другой рабочий процесс заключается в перебазировании. Здесь есть три варианта:

  1. На самом деле не совершайте свою работу. Просто внесите изменения другого пользователя в ваше дерево, обновите (которое будет объединено, где это необходимо), затем подтвердите и нажмите. Очевидно, это работает, только если у вас есть один коммит для пуша за раз.
  2. ртутные очереди. Это равносильно временному отмене ваших патчей, добавлению последней работы в ваш клон, затем повторному применению ваших патчей и фиксации. Однако исправления не применяются интеллектуально, и вы можете столкнуться с конфликтами слияния.
  3. Перебазировать расширение. Это новее и потому умнее. Для отдельного набора изменений он напоминает коммит слияния, но затем он удаляет ваш исходный коммит, оставляя набор изменений только с изменениями другого пользователя в качестве родителя. Расширение rebase может даже перебазировать вашу очередь Mercurial для вас.
2 голосов
/ 01 декабря 2011

Я не могу говорить за Mercurial, но в Git слияния обрабатываются автоматически, за исключением случаев, когда два человека изменяют одно и то же местоположение в одном и том же файле.

Если это происходит, второй человек, который регистрируется, долженобъединить изменения.Файл будет выглядеть примерно так:

<<<<<<<<<<
void SomeMethod()
{
    // do something
}
==========
void SomeMethod()
{
    // do something else
}
>>>>>>>>>>

Основная идея заключается в том, что вы, как человек, который понимает код, выясните, как объединить изменения в двух разделах, а затем удалите символы маркера,Я могу сделать это, комбинируя два, если это уместно:

void SomeMethod()
{
    // do something
    // do something else
}

Или я мог бы просто использовать одно, если оно заменяет другое:

void SomeMethod()
{
    // do something else
}

Затем я добавляю объединенный файл и заканчиваюкоммит.Или, если я не уверен, что изменения имеют смысл, я могу провести столько испытаний, сколько захочу, до завершения фиксации.

Помимо слияния, вы также можете rebase ,Это меняет природу истории, так что вместо вас и другого человека, делающего одновременные изменения, ваша история ставится после его.Но хотя перебазирование меняет внешний вид истории, это не меняет того факта, что если вы двое изменили одну и ту же часть файла, вам придется объединить изменения вместе.Rebase (и любая другая потенциально возможная операция слияния, такая как применение / вытаскивание тайника или выборка вишни для коммитов) будут вызывать конфликты так же, как описано выше.

0 голосов
/ 01 декабря 2011

Ответ для git зависит от ваших настроек для git pull.

Когда пользователь # 2 пойдет в пуш, пуш не будет выполнен, потому что общий репо изменился.Пользователь # 2 должен будет потянуть, прежде чем нажать.

По умолчанию git pull представляет собой комбинацию git fetch и git merge.Тем не менее, git pull также может быть настроен на git fetch, за которым следует git rebase.

git fetch обновляет локальное представление удаленного репо.Git поддерживает эту область для вас автоматически.

В режиме по умолчанию, используя git merge, git объединит изменения из удаленного репо в локальное репо.Это создает впечатление, что изменения для пользователя # 1 произошли после изменений для пользователя # 2.Это также может создать так называемый коммит слияния.

В режиме перебазирования все локальные изменения в ветке сохраняются, ветка обновляется из удаленного представления, затем локальные изменения воспроизводятся поверх ветки.Таким образом, изменения для пользователя # 1 происходят до изменений для пользователя # 2.

Вся информация от @Kyralessa верна в отношении конфликтов слияния.Конфликты слияния могут возникать с слиянием или с перебазированием.

Редакция

Мы предпочитаем использовать git rebase с git pull.Это более правильно представляет историю удаленного репо.В этом примере пользователь # 1 отправил изменения в пульт дистанционного управления до пользователя # 2, и история должна отражать это.git pull с rebase также позволяет избежать нежелательного побочного эффекта коммитов слияния.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...