Несколько пользователей в Git, поступающие от использования Mercurial

Question

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

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

Произойдет ли то же самое в git?Могут ли несколько пользователей работать только в основной ветке, а затем объединять новые изменения, как в Mercurial, когда они тянут?Или ты должен делать ветки?Или я просто думаю об этом неправильно?

Answer 1

Учитывая то, что вы объяснили, вы должны работать с git таким же образом.

С mercurial, как и с git, ваши два разработчика начали разрабатывать функции из той же точки M. Dev 1 создает M1 через его / ееизменения, dev 2 создает M2.

В основном, первый разработчик, который толкает, выигрывает.Если это dev1, когда dev2 пытается и нажать M-> M2, push не удастся, потому что точка удаленного доступа на самом деле M1, а не M.

Это означает, что у dev2 есть два варианта:

• либо (s) он извлекает из удаленного узла, и в этом случае будет создан коммит слияния, который можно будет использовать;
• или (s) он получит и перебазирует свою ревизию поверх M1, создает M2 'и толкает.

В первом случае последовательность команд выглядит следующим образом:

git pull origin master
git push origin master

( обратите внимание, что при случайной настройке originи master по умолчанию являются remote и branch по умолчанию, что означает, что эти аргументы являются необязательными ... Поэтому эти команды, вероятно, излишни. Но я не люблю сюрпризов: p )

, и дерево будетbe:

M---...---M1--C    # C is a merge commit
 \           /
  \---.....M2

Во втором случае последовательность команд будет:

git fetch origin
git rebase origin/master
git push origin master

и дерево будет:

M ---...M1---...----M2'  # M2 rebased on top of M1

Теперь, какое решениевыбран действительно о политике.Некоторые проекты предпочитают решение 1, другие предпочитают решение 2. Git не заботится о политике;)