В чем разница между Mercurial и Git?
Я уже некоторое время использую git в Windows (с msysGit), и мне нравится идея распределенного управления исходным кодом. Совсем недавно я смотрел на Mercurial (HG), и это выглядит интересно. Тем не менее, я не могу обернуть голову вокруг различий между ртутью и мерзавцем.
Кто-нибудь делал параллельное сравнение между git и hg? Мне интересно знать, чем отличаются hg и git, не вступая в дискуссию фанатов.
25 ответов
Эти статьи могут помочь:
- Git vs. Mercurial: пожалуйста, расслабьтесь (Git - МакГайвер, а Mercurial - Джеймс Бонд)
- Различия между Mercurial и Git
Изменить: Сравнение Git и Mercurial со знаменитостями, кажется, тенденция. Вот еще один:
Я работаю над Mercurial, но, по сути, считаю, что обе системы эквивалентны. Они оба работают с одними и теми же абстракциями: серией снимков (наборов изменений), которые составляют историю. Каждый набор изменений знает, откуда он (родительский набор изменений) и может иметь много дочерних наборов изменений. Недавнее расширение hg-git обеспечивает двусторонний мост между Mercurial и Git и как бы показывает эту точку зрения.
Git уделяет большое внимание изменению этого графа истории (со всеми вытекающими отсюда последствиями), тогда как Mercurial не поощряет переписывание истории, но в любом случае это легко сделать, и последствия этого - именно то, чего и следует ожидать (то есть Если я изменю уже имеющуюся у вас ревизию, ваш клиент увидит ее как новую, если вы от меня откажетесь). Так что у Mercurial есть склонность к неразрушающим командам.
Что касается легких веток, то Mercurial поддерживает репозитории с несколькими ветками с тех пор..., я всегда думаю. Git-репозитории с несколькими ветвями - это именно то, что: несколько расходящихся цепочек развития в одном репозитории. Затем Git добавляет имена к этим цепям и позволяет удаленно запрашивать эти имена. Расширение Bookmarks для Mercurial добавляет локальные имена, а с Mercurial 1.6 вы можете перемещать эти закладки, когда нажимаете / вытягиваете.
Я использую Linux, но, по-видимому, TortoiseHg работает быстрее и лучше, чем Git-эквивалент в Windows (из-за лучшего использования плохой файловой системы Windows). И http://github.com/ и http://bitbucket.org/ предоставляют онлайн-хостинг, сервис в Bitbucket отличный и отзывчивый (я не пробовал github).
Я выбрал Mercurial, так как он выглядит чистым и элегантным - меня оттолкнули скрипты shell/Perl/Ruby, которые я получил с Git. Попробуйте взглянуть на git-instaweb.sh файл, если вы хотите знать, что я имею в виду: это сценарий оболочки, который генерирует сценарий Ruby, который, я думаю, запускает веб-сервер. Сценарий оболочки создает другой сценарий оболочки для запуска первого сценария Ruby. Существует также немного Perl, для хорошей меры.
Мне нравится сообщение в блоге, в котором сравниваются Mercurial и Git с Джеймсом Бондом и МакГайвером - Mercurial чем-то более сдержан, чем Git. Мне кажется, что люди, использующие Mercurial, не так легко впечатляются. Это отражается в том, как каждая система делает то, что Линус назвал "самым классным слиянием!", В Git вы можете объединиться с несвязанным хранилищем, выполнив:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
Эти команды выглядят довольно загадочно на мой взгляд. В Mercurial мы делаем:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Обратите внимание, что команды Mercurial простые и совсем не особенные - единственная необычная вещь --force флаг для hg pull, что необходимо, поскольку в противном случае Mercurial прервет работу, когда вы извлечете из несвязанного репозитория. Именно такие различия делают Mercurial более элегантным для меня.
Git - это платформа, Mercurial - "просто" приложение. Git - это версионная платформа файловой системы, которая поставляется с приложением DVCS в комплекте, но, как обычно, для приложений платформы, она более сложна и имеет более грубые края, чем специализированные приложения. Но это также означает, что VCS git чрезвычайно гибок, и есть огромная глубина вещей, не связанных с управлением исходным кодом, которые вы можете делать с git.
В этом суть разницы.
Git лучше всего понимается с нуля - из формата репозитория. Git Talk Скотта Чакона - отличный учебник для этого. Если вы попытаетесь использовать git, не зная, что происходит под капотом, в какой-то момент вы будете в замешательстве (если вы не будете придерживаться только самых базовых функций). Это может показаться глупым, когда все, что вам нужно, это DVCS для вашей повседневной программы, но гениальность git заключается в том, что формат репозитория на самом деле очень прост, и вы можете легко понять всю работу git.
Для некоторых сравнений, ориентированных на техническую специфику, лучшими статьями, которые я лично видел, были Дастин Саллингс:
- Различия между Mercurial и Git
- Тема Reddit, где опытный мерзавец Дастин отвечает на свои вопросы о неопытном мерзавце
На самом деле он широко использовал обе DVCS и хорошо их понимает - и в итоге предпочел git.
Большая разница в Windows. Mercurial поддерживается изначально, а Git - нет. Вы можете получить очень похожий хостинг с http://www.github.com/ с помощью http://bitbucket.org/ (на самом деле даже лучше, если вы получите бесплатный частный репозиторий). Некоторое время я использовал msysGit, но перешел на Mercurial и был очень доволен этим.
Если вы разработчик Windows и ищете базовое отключенное управление версиями, используйте Hg. Я обнаружил, что Git непостижим, в то время как Hg был прост и хорошо интегрирован с оболочкой Windows. Я скачал Hg и последовал этому уроку (hginit.com) - через десять минут у меня было локальное репо, и я вернулся к работе над своим проектом.
Я думаю, что лучшее описание "Mercurial vs. Git" это:
Они практически идентичны. Самое важное различие, с моей точки зрения (я имею в виду причину, по которой я выбрал одну DVCS вместо другой), заключается в том, как две программы управляют филиалами.
Чтобы начать новую ветку с Mercurial, вы просто клонируете репозиторий в другой каталог и начинаете разработку. Затем вы тянете и сливаете. С помощью git вы должны явно дать имя новой ветке темы, которую хотите использовать, затем вы начнете кодировать, используя тот же каталог.
Короче говоря, каждая ветвь в Mercurial нуждается в своем собственном каталоге; в git вы обычно работаете с одним каталогом. Переключение филиалов в Mercurial означает изменение каталогов; в git это означает, что нужно попросить git изменить содержимое каталога с помощью git checkout.
Я честен: я не знаю, возможно ли сделать то же самое с Mercurial, но, поскольку я обычно работаю над веб-проектами, использование всегда одного и того же каталога с git кажется мне очень удобным, так как мне не нужно -конфигурировать Apache и перезапустить его, и я не путаю свою файловую систему каждый раз, когда я разветвляюсь.
Редактировать: Как отметил Дестан, Hg имеет именованные ветви, которые могут храниться в одном репозитории и позволяют разработчику переключать ветви внутри одной рабочей копии. В любом случае, ветки git не совпадают с ветвями, названными Mercurial: они постоянны и не выбрасывают ветки, как в git. Это означает, что если вы используете именованную ветвь для экспериментальных задач, даже если вы решите никогда не объединять ее, она будет сохранена в хранилище. Вот почему Hg рекомендует использовать клоны для экспериментальных, краткосрочных задач и именованные ветви для долгосрочных задач, например, для веток релиза.
Причина, по которой многие пользователи ртути предпочитают клонов перед именованными ветвями, гораздо более социальная или культурная, чем техническая. Например, в последних версиях Hg даже можно закрыть именованную ветвь и рекурсивно удалить метаданные из наборов изменений.
С другой стороны, git предлагает использовать "именованные ветви", которые не являются постоянными и не хранятся в виде метаданных для каждого набора изменений.
Таким образом, с моей личной точки зрения, модель git тесно связана с концепцией именованных ветвей и переключением между ветвью и другой в том же каталоге; hg может делать то же самое с именованными ветвями, но все же поощряет использование клонов, которые лично мне не очень нравятся.
Есть одно огромное различие между мерзавцем и мерзавцем; способ представления каждого коммита. git представляет коммиты в виде снимков, а mercurial представляет их в виде различий.
Что это значит на практике? В git многие операции выполняются быстрее, например переключение на другой коммит, сравнение коммитов и т. Д. Особенно, если эти коммиты находятся далеко.
AFAIK, нет никакого преимущества подхода Mercurial.
Ничего такого. Они оба делают то же самое, оба работают примерно одинаково. Единственная причина, по которой вы должны выбрать один, а другой - если вы помогаете с проектом, который уже использует один..
Другая возможная причина выбора - приложение или служба, которая поддерживает только одну из систем. Например, я в значительной степени выбрал изучение git из-за github.
Если я правильно их понимаю (и я далеко не эксперт по каждому из них), у каждого из них есть философия. Я впервые использовал ртуть в течение 9 месяцев. Теперь я использовал git для 6.
hg - программное обеспечение для контроля версий. Его главная цель - отслеживать версии программного обеспечения.
git - это файловая система, основанная на времени. Его цель - добавить еще одно измерение в файловую систему. У большинства есть файлы и папки, Git добавляет время. То, что это работает потрясающе, поскольку VCS является побочным продуктом его дизайна.
В hg, есть история всего проекта, который он всегда пытается сохранить. По умолчанию я считаю, что hg хочет, чтобы все изменения во всех объектах были всеми пользователями при нажатии и вытягивании.
В git есть просто пул объектов и эти файлы отслеживания (ветви / головы), которые определяют, какой набор этих объектов представляет дерево файлов в определенном состоянии. При нажатии или вытягивании git отправляет только те объекты, которые необходимы для определенных веток, которые вы нажимаете или тянете, что является небольшим подмножеством всех объектов.
Что касается git, то здесь нет "1 проекта". У вас может быть 50 проектов в одном репо, и git это не волнует. Каждый из них может управляться отдельно в том же репо и жить хорошо.
Концепция веток Hg - это ветви основного проекта или ветви филиалов и т. Д. У Git такой концепции нет. Ветвь в git - это просто состояние дерева, все в git - это ветвь. Какая ветка является официальной, текущей или новейшей, не имеет значения в git.
Я не знаю, имело ли это смысл. Если бы я мог рисовать картинки, hg мог бы выглядеть так, где каждый коммит o
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Дерево с одним корнем и ветвями, выходящими из него. Хотя git может это делать, и часто люди используют его таким образом, который не применяется. Git картина, если есть такая вещь, может легко выглядеть следующим образом
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
На самом деле, в некоторых случаях даже нет смысла показывать ветки в git.
Одна вещь, которая очень сбивает с толку для обсуждения, и git, и mercurial имеют нечто, называемое "ветвью", но они не являются отдаленно одинаковыми вещами. Ветвь в Mercurial возникает, когда возникают конфликты между разными репозиториями. Ветвь в git, по-видимому, похожа на клон в hg. Но клон, хотя он может дать похожее поведение, совершенно определенно не тот. Считай, что я пробовал это в git vs hg, используя довольно большое хранилище хрома.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
А теперь в рт с помощью клона
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
Оба из этих горячих трасс. То есть я запускал их дважды, и это второй запуск. hg clone фактически такой же, как git-new-workdir. Оба из них делают совершенно новый рабочий каталог, как будто вы набрали cp -r project project-clone, Это не то же самое, что создание новой ветки в git. Это гораздо более тяжелый вес. Если есть истинный эквивалент ветвления git в hg, я не знаю, что это такое.
Я понимаю, что на каком-то уровне hg и git могут делать подобные вещи. Если так, то есть еще огромная разница в рабочем процессе, к которому они вас ведут. В git типичным рабочим процессом является создание ветки для каждой функции.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
Это только что создало 3 ветви, каждая из которых основана на ветви, называемой master. (Я уверен, что в git есть способ сделать эти 1 строку вместо 2)
Теперь работать над одним я просто делаю
git checkout fix-game-save-bug
и начать работать. Фиксация и т. Д. Переключение между ветвями даже в таком большом проекте, как Chrome, происходит практически мгновенно. Я на самом деле не знаю, как это сделать в HG. Это не часть каких-либо руководств, которые я прочитал.
Еще одна большая разница. Стадия Гита.
У Git есть эта идея сцены. Вы можете думать об этом как о скрытой папке. Когда вы фиксируете, вы фиксируете только то, что находится на сцене, а не изменения в вашем рабочем дереве. Это может звучать странно. Если вы хотите зафиксировать все изменения в вашем рабочем дереве, вы должны сделать git commit -a который добавляет все измененные файлы на сцену, а затем фиксирует их.
Какой смысл на сцене тогда? Вы можете легко отделить ваши коммиты. Представьте, что вы отредактировали joypad.cpp и gamesave.cpp и хотите зафиксировать их отдельно
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
У Git даже есть команды, чтобы решить, какие именно строки в одном и том же файле вы хотите скопировать на сцену, чтобы вы также могли разделить эти коммиты по отдельности. Почему вы хотите это сделать? Поскольку в качестве отдельных коммитов другие могут извлекать только те, которые им нужны, или, если возникла проблема, они могут отменить только коммит, в котором возникла проблема.
Также сравнение Google (хотя это немного устарело, сделано в 2008 году)
В файле versioncontrolblog есть таблица динамического сравнения, где вы можете сравнить несколько разных систем контроля версий.
Существуют довольно существенные различия в работе с филиалами (особенно кратковременными).
Это объясняется в этой статье (BranchingExplained), которая сравнивает Mercurial с Git.
Между mercurial bitbucket.org и git github следует заметить, что у mercurial может быть столько частных репозиториев, сколько вы хотите, но github вам нужно перейти на платную учетную запись. Итак, вот почему я иду на битбакет, который использует Mercurial.
Есть ли в вашем проекте соавторы на базе Windows?
Потому что, если таковые имеются, графический интерфейс Git-for-Windows кажется неловким, трудным, недружественным.
Mercurial-on-Windows, напротив, не представляет никакой сложности.
Когда-то в прошлом году я оценил и git, и hg для собственного использования, и решил пойти с hg. Я чувствовал, что это выглядело как более чистое решение, и в то время работало лучше на большем количестве платформ. Хотя, в основном, это были проблемы.
Совсем недавно я начал использовать git из-за git-svn и способности выступать в качестве клиента Subversion. Это покорило меня, и теперь я полностью переключился на мерзавца. Я думаю, что у него немного более высокая кривая обучения (особенно если вам нужно разбираться в недрах), но это действительно отличная система. Я собираюсь прочитать эти две сравнительные статьи, которые Джон разместил сейчас.
В руководстве InfoQ по DVCS есть отличные и исчерпывающие сравнительные таблицы и диаграммы для git, Mercurial и Bazaar.
В настоящее время я нахожусь в процессе перехода от SVN к DVCS (в то время как веду блог о моих результатах, о моих первых реальных усилиях по ведению блога...), и я провел небольшое исследование (= поиск в Google). Насколько я вижу, вы можете делать большинство вещей с обоими пакетами. Похоже, что в git реализовано несколько или более улучшенных расширенных функций, я чувствую, что интеграция с Windows немного лучше для Mercurial, с TortoiseHg. Я знаю, что есть и Git Cheetah (я пробовал оба), но ртутное решение кажется более надежным.
Видя, как они оба с открытым исходным кодом (не так ли?), Я не думаю, что ни у одного из них не будет важных функций. Если что-то важно, люди будут просить об этом, люди будут кодировать это.
Я думаю, что для обычных практик Git и Mercurial более чем достаточно. У них обоих есть большие проекты, которые используют их (Git -> ядро linux, Mercurial -> проекты Mozilla Foundation, конечно же, оба среди других), так что я не думаю, что им чего-то действительно не хватает.
При этом мне интересно, что другие люди говорят по этому поводу, так как это послужило бы отличным источником для моих усилий по ведению блога;-)
Я понимаю, что это не часть ответа, но на этом замечании, я также думаю, что наличие стабильных плагинов для платформ, таких как NetBeans и Eclipse, играет роль, в которой инструмент лучше подходит для задачи, или, скорее, какой инструмент лучше всего подходит для "вы". То есть, если вы действительно не хотите делать это CLI-способом.
И Eclipse (и все, что на нем основано) и NetBeans иногда имеют проблемы с удаленными файловыми системами (такими как SSH) и внешними обновлениями файлов; что является еще одной причиной, почему вы хотите, чтобы все, что вы выбрали, работало "без проблем".
Я тоже сейчас пытаюсь ответить на этот вопрос для себя... и я сварил кандидатов в Git или Mercurial ... спасибо всем за то, что предоставили полезные материалы по этой теме, не переходя на религиозную тему.
Если вы заинтересованы в сравнении производительности Mercurial и Git, взгляните на эту статью. Вывод:
Git и Mercurial дают хорошие цифры, но делают компромисс между скоростью и размером репозитория. Mercurial работает быстро как с добавлениями, так и с модификациями, и в то же время держит под контролем рост хранилища. Git также работает быстро, но его хранилище очень быстро растет с измененными файлами, пока вы не перепаковаете - и эти перепаковки могут быть очень медленными. Но упакованный репозиторий намного меньше, чем у Mercurial.
Еще одно интересное сравнение Mercurial и Git: Mercurial против Git. Основное внимание уделяется внутренним компонентам и их влиянию на процесс ветвления.
Если вы переходите с SVN, используйте Mercurial, так как его синтаксис НАМНОГО более понятен для пользователей SVN. Кроме этого, вы не можете пойти не так, как надо. Но перед тем, как выбрать один из них, проверьте руководство GIT и HGinit.
Веб-сайт Mercurial имеет отличное описание сходства и различий между двумя системами, объясняя различия словарного запаса и основных понятий. Как давний пользователь git, это действительно помогло мне понять образ мышления Mercurial.
Некоторые люди думают, что системы VCS должны быть сложными. Они поощряют придумывать термины и концепции на местах. Вероятно, они подумают, что множество докторов наук по этому вопросу было бы интересно. Среди них, вероятно, те, которые разработали Git.
Mercurial разработан с другим менталитетом. Разработчики не должны заботиться о VCS, и вместо этого они должны тратить свое время на их основную функцию: разработку программного обеспечения. Mercurial позволяет пользователям использовать и счастливо ругать систему, не позволяя им делать какие-либо неустранимые ошибки.
Любой профессиональный инструмент должен иметь четко разработанный и интуитивно понятный интерфейс командной строки. Пользователи Mercurial могут выполнять большую часть работы, выполняя простые команды без каких-либо странных опций. В Git double dash сумасшедшие варианты являются нормой. Mercurial имеет существенное преимущество, если вы являетесь пользователем CLI (и, честно говоря, любой уважающий себя инженер-программист должен быть).
В качестве примера предположим, что вы делаете коммит по ошибке. Вы забыли отредактировать некоторые файлы. Чтобы отменить действие в Mercurial, просто введите:
$ hg rollback
Затем вы получите сообщение, что система отменяет вашу последнюю транзакцию.
В Git вы должны ввести:
$ git reset --soft HEAD^
Итак, предположим, у вас есть представление о том, что такое сброс. Но, кроме того, вы должны знать, что такое "--soft" и "--hard" (какие-нибудь интуитивные предположения?). О, и, конечно же, не забывайте символ '^' в конце! (теперь то, что в имени Ричи это...)
Интеграция Mercurial со сторонними инструментами, такими как kdiff3 и meld, также намного лучше. Создавайте свои патчи, объединяйте свои ветви без особой суеты. Mercurial также включает в себя простой http-сервер, который вы активируете, набрав
hg serve
И пусть другие просматривают ваш репозиторий.
Суть в том, что Git делает то, что делает Mercurial, гораздо более сложным способом и с намного худшим CLI. Используйте Git, если хотите превратить VCS вашего проекта в научно-исследовательскую область. Используйте Mercurial, если вы хотите выполнить работу VCS, не заботясь об этом, и сосредоточиться на ваших реальных задачах.
Эта ссылка может помочь вам понять разницу http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/