В чем разница между Mercurial и Git?
https://stackoverflow.com/questions/35837
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я уже некоторое время использую git в Windows (с msysGit), и мне нравится идея распределенного управления версиями.Совсем недавно я рассматривал Mercurial (hg), и это выглядит интересно.Тем не менее, я не могу разобраться в различиях между hg и git.
Кто-нибудь проводил параллельное сравнение между git и hg?Мне интересно узнать, чем отличаются hg и git, не вдаваясь в дискуссию фанатов.
Решение
Эти статьи могут помочь:
- Мерзавец противПеременчивый:Пожалуйста, расслабься (Мерзавец - это Макгайвер, а Меркуриал - Джеймс Бонд)
- Различия между Mercurial и Git
Редактировать:Сравнение Git и Mercurial со знаменитостями, похоже, стало тенденцией.Вот еще один:
Другие советы
Я работаю над Mercurial, но в целом я считаю, что обе системы эквивалентны. Они оба работают с одними и теми же абстракциями: серией снимков (наборов изменений), которые составляют историю. Каждый набор изменений знает, откуда он (родительский набор изменений) и может иметь много дочерних наборов изменений. Недавнее расширение hg-git обеспечивает двусторонний мост между Mercurial и Git, и в некотором роде это показывает .
Git уделяет особое внимание изменению этого графа истории (со всеми вытекающими последствиями), тогда как Mercurial не поощряет переписывание истории, но в любом случае это легко сделать , и последствия этого будут именно такими, как вы и ожидаете (то есть, если я изменю уже существующий набор изменений, ваш клиент увидит его как новый, если вы меня потянете). Таким образом, Mercurial имеет уклон в отношении неразрушающих команд.
Что касается легких веток, то Mercurial поддерживает репозитории с несколькими ветками с тех пор ..., я всегда так думаю. Git-репозитории с несколькими ветвями - это именно то, что: несколько расходящихся цепочек развития в одном репозитории. Затем Git добавляет имена к этим цепям и позволяет вам запрашивать эти имена удаленно. Расширение Закладки для Mercurial добавляет локальные имена, и с помощью Mercurial 1.6 вы можете перемещать эти закладки вокруг, когда вы толкаете / тянете ..
Я использую Linux, но, очевидно, TortoiseHg работает быстрее и лучше, чем Git-эквивалент в Windows (из-за лучшего использования плохой файловой системы Windows). http://github.com и http://bitbucket.org предоставляет онлайн-хостинг, сервис в Bitbucket отличный и отзывчивый (я не пробовал github).
Я выбрал Mercurial, так как он выглядит чистым и элегантным - меня оттолкнули скрипты shell / Perl / Ruby, которые я получил с Git. Попробуйте взглянуть на < code> git-instaweb.sh file , если вы хотите знать, что я имею в виду: это скрипт shell , который генерирует скрипт 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, не зная, что происходит под капотом, в какой-то момент вы окажетесь в замешательстве (если только вы не будете придерживаться только самой базовой функциональности).Это может показаться глупым, когда все, что вам нужно, - это DVCS для вашего ежедневного программирования, но гениальность git в том, что формат репозитория на самом деле очень прост, и вы может понять всю работу git довольно легко.
Для сравнения, ориентированного на технические аспекты, лучшие статьи, которые я лично видел, - это статья Дастина Саллингса:
- Различия между Mercurial и Git
- Ветка Reddit, где опытный в git Дастин отвечает на свои собственные вопросы новичка в git
На самом деле он широко использовал оба DVCSS и хорошо понимает их оба - и в конечном итоге предпочел git.
Большая разница в Windows. Mercurial поддерживается изначально, а Git - нет. Вы можете получить очень похожий хостинг на github.com с 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 представляет коммиты в виде снимков, а mercurial представляет их в виде различий.
Что это значит на практике? В git многие операции выполняются быстрее, например переключение на другой коммит, сравнение коммитов и т. Д. Особенно, если эти коммиты находятся далеко.
AFAIK, нет никакого преимущества от подхода Mercurial.
Ничего.Они оба делают одно и то же, оба работают примерно одинаково.Единственная причина, по которой вам следует предпочесть один другому, - это если вы помогаете проекту, в котором он уже используется..
Другой возможной причиной выбора одного из них является приложение или служба, которые поддерживают только одну из систем..Например, я в значительной степени решил изучать git из-за гитхаб..
Также сравнение Google (хотя оно немного старое, сделано в 2008 году)
Если я правильно их понимаю (и я далеко не эксперт по каждому из них), у каждого из них есть своя философия. Я впервые использовал ртуть в течение 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 может это делать, и часто люди используют его таким образом, который не применяется. Картинка мерзавца, если она есть, легко может выглядеть так
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
А теперь в hg с помощью клона
$ 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 , который добавит все измененные файлы
В файле versioncontrolblog приведена динамическая сравнительная таблица, в которой вы можете сравнить несколько разных систем контроля версий.
Существуют довольно существенные различия в работе с ветками (особенно кратковременными).
Это объясняется в этой статье (BranchingExplained) , в которой сравнивается Mercurial с Git.
Есть ли в вашем проекте соавторы для Windows?
Потому что, если есть, графический интерфейс Git-for-Windows кажется неуклюжим, трудным, недружелюбным.
Mercurial-on-Windows, напротив, не представляет никакой сложности.
Между mercurial of bitbucket.org и git of github следует заметить, что у mercurial может быть столько личных репозиториев, сколько вы хотите, но с github вам нужно перейти на платную учетную запись. Итак, вот почему я иду на битбакет, который использует Mercurial.
Когда-то в прошлом году я оценил git и hg для своего собственного использования и решил использовать hg. Я чувствовал, что это выглядело как более чистое решение, и в то время работало лучше на большем количестве платформ. Тем не менее, это был в основном бросок.
Совсем недавно я начал использовать git из-за git-svn и способности выступать в качестве клиента Subversion. Это покорило меня, и теперь я полностью переключился на мерзавца. Я думаю, что у него немного более высокая кривая обучения (особенно если вам нужно разбираться в недрах), но это действительно отличная система. Я собираюсь прочитать эти две сравнительные статьи, которые Джон разместил сейчас.
В настоящее время я нахожусь в процессе перехода с SVN на DVCS (пока веду блог о своих находках, моя первая настоящая попытка ведения блога ...), и я провел небольшое исследование (= погуглил).Насколько я могу судить, вы можете делать большинство вещей с обоими пакетами.Похоже, что у git есть несколько более или лучше реализованных расширенных функций, Я действительно чувствую, что интеграция с Windows немного лучше для mercurial, с TortoiseHg.Я знаю, что есть еще Git Cheetah (я пробовал оба варианта), но решение mercurial просто кажется более надежным.
Учитывая, что они оба с открытым исходным кодом (верно?) Я не думаю, что ни в одном из них не будет недостатка в важных функциях.Если что-то важно, люди будут просить об этом, люди будут кодировать это.
Я думаю, что для обычных практик Git и Mercurial более чем достаточно.У них обоих есть большие проекты, которые их используют (Git -> ядро Linux, Mercurial -> Проекты Mozilla foundation, оба среди прочих, конечно), так что я не думаю, что им действительно чего-то не хватает.
Тем не менее, мне интересно, что другие люди говорят об этом, поскольку это стало бы отличным источником для моих усилий по ведению блога ;-)
На ga, Mercurial и Bazaar есть отличные и исчерпывающие сравнительные таблицы и диаграммы на InfoQ. руководство по DVCS .
Я понимаю, что это не часть ответа, но в этой заметке я также думаю, что наличие стабильных плагинов для платформ, таких как NetBeans и Eclipse, играет роль, в которой инструмент лучше подходит для задачи, или, скорее, какой инструмент лучше всего подходит для "вас". То есть, если вы действительно не хотите делать это с помощью CLI.
И Eclipse (и все, что на нем основано) и NetBeans иногда имеют проблемы с удаленными файловыми системами (такими как SSH) и внешними обновлениями файлов; это еще одна причина, по которой вы хотите, чтобы все, что вы выбрали, работало «без проблем».
Я тоже сейчас пытаюсь ответить на этот вопрос для себя ... и я сварил кандидатов в Git или Mercurial ... спасибо всем за предоставление полезных материалов по этой теме, не переходя в религиозное русло.
Еще одно интересное сравнение Mercurial и Git: Mercurial против Git . Основное внимание уделяется внутренним компонентам и их влиянию на процесс ветвления.
Если вы заинтересованы в сравнении производительности Mercurial и Git, ознакомьтесь с этой статьей . Вывод такой:
Git и Mercurial оба показывают хорошие цифры, но делают интересный компромисс между скоростью и размером хранилища. Mercurial работает как с добавлениями, так и с модификациями, и в то же время держит под контролем рост хранилища. Git также быстр, но его репозиторий очень быстро растет с измененными файлами, пока вы не перепаковаете - и эти перепаковки могут быть очень медленными. Но упакованный репозиторий намного меньше, чем у Mercurial.
На веб-сайте Mercurial есть отличное описание сходства и различий между двумя системами, объясняющее различия словарного запаса и основных понятий. Как давний пользователь git, это действительно помогло мне понять образ мышления Mercurial.
Если вы переходите с SVN, используйте Mercurial, так как его синтаксис НАМНОГО более понятен для пользователей SVN. Кроме этого, вы не можете пойти не так, как надо. Но посмотрите учебник по GIT и HGinit перед выбором одного из них.
Эта ссылка может помочь вам понять разницу http://www.techtatva.com/2010/ 09 / ГИТ-ртутного-и-базар-а-сравнение /
Некоторые люди думают, что системы VCS должны быть сложными. Они поощряют придумывать термины и концепции на местах. Они, вероятно, подумают, что многочисленные доктора наук по этому вопросу будут интересны. Среди них, вероятно, те, которые разработали Git.
Mercurial разработан с другим менталитетом. Разработчики не должны заботиться о VCS, и вместо этого они должны тратить свое время на их основную функцию: разработку программного обеспечения. Mercurial позволяет пользователям использовать и счастливо ругать систему, не позволяя им делать какие-либо невосстановимые ошибки.
Любой профессиональный инструмент должен иметь четко разработанный и интуитивно понятный интерфейс командной строки. Пользователи Mercurial могут выполнять большую часть работы, выполняя простые команды без каких-либо странных опций. В Git double dash сумасшедшие варианты являются нормой. Mercurial имеет существенное преимущество, если вы являетесь пользователем CLI (и, честно говоря, любой уважающий себя инженер-программист должен быть).
Предположим, вы сделали коммит по ошибке. Вы забыли отредактировать некоторые файлы. Чтобы отменить действие в Mercurial, просто введите:
откат $ hg
Затем вы получите сообщение о том, что система отменяет вашу последнюю транзакцию.
В Git вы должны ввести:
$ git reset --soft HEAD ^
Итак, предположим, у вас есть представление о том, что такое сброс. Но кроме того, вы должны знать, что такое "soft" и " - жесткий " Сбросы есть (какие-нибудь интуитивные догадки?). О, и, конечно же, не забывайте символ «^» в конце! (теперь то, что по имени Ричи это ...)
Интеграция Mercurial со сторонними инструментами, такими как kdiff3 и meld, также намного лучше. Создавайте свои патчи, объединяйте свои ветви без особой суеты. Mercurial также включает в себя простой http-сервер, который вы активируете, набирая
hg serve
И пусть другие просматривают ваш репозиторий.
Суть в том, что Git делает то, что делает Mercurial, гораздо более сложным способом и с намного худшим CLI. Используйте Git, если хотите превратить VCS вашего проекта в научно-исследовательскую область. Используйте Mercurial, если вы хотите выполнить работу VCS, не заботясь об этом, и сосредоточьтесь на реальных задачах.
