В чем разница между Mercurial и Git?

Я работаю над Mercurial, но в основном я считаю, что обе системы эквивалентны. Они оба работают с одними и теми же абстракциями: серией снимков (наборов изменений), которые составляют историю. Каждый набор изменений знает, откуда он пришел (Родительский набор изменений), и может иметь много дочерних наборов изменений. Последние hg-git расширение обеспечивает двусторонний мост между Mercurial и Git и вроде показывает эту точку.

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

Что касается легких ветвей, то Mercurial поддерживает репозитории с отделения так... я всегда думаю. Репозитории Git с несколькими ветвями-это именно то, что: несколько расходящихся нитей разработки в одном репозитории. Затем Git добавляет имена к этим нитям и позволяет запрашивать эти имена удаленно. The закладки расширение для Mercurial добавляет локальные имена, и с Mercurial 1.6 вы можете перемещать эти закладки, когда вы нажимаете/тянете..

Я использую Linux, но, по-видимому, TortoiseHg быстрее и лучше чем эквивалент Git на Windows (из-за лучшего использования плохой файловой системы Windows). Оба http://github.com и http://bitbucket.org предоставление онлайн-хостинга, сервис в Bitbucket отличный и отзывчивый (я не пробовал github).

Я выбрал Mercurial, так как он чувствует себя чистым и элегантным-меня отпугнули скрипты shell/Perl/Ruby, которые я получил с Git. Попробуйте взглянуть на если вы хотите знать, что я имею в виду: это shell скрипт, который генерирует Рубин скрипт, который я думаю работает вебсервер. Скрипт генерирует другой скрипт для запуска первого скрипта. Существует также немного 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 заключается в том, что формат репозитория на самом деле очень прост, и вы can понять всю работу git довольно легко.

еще какое-то формальности-ориентированного сравнения, лучшие статьи, которые я лично видел несколько Sallings Дастин’:

• различия между Mercurial и Git
• Reddit нить, где git-опытный Дастин отвечает на свои собственные вопросы git неофит

Он на самом деле широко использовал оба DVCSs и хорошо их понимает – и в конечном итоге предпочел git.

большая разница в Windows. Mercurial поддерживается изначально, Git-нет. Вы можете получить очень похожий хостинг наgithub.com с bitbucket.org (на самом деле даже лучше, когда вы получаете бесплатный частный репозиторий). Некоторое время я использовал msysGit, но перешел на Mercurial и был очень доволен этим.

Если вы разработчик Windows, ищущий базовый отключенный контроль версий, перейдите к Hg. Я нашел Git непонятным, в то время как Hg был простым и хорошо интегрированным с оболочкой Windows. Я загрузил Hg и последовал этот учебник (hginit.com)

Я думаю, что лучшее описание о "Меркуриал и ГИТ" является:

Они почти идентичны. Самое важное различие, с моей точки зрения (я имею в виду, причина, по которой я выбрал один DVCS над другим), заключается в том, как две программы управляют ветвями.

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

короче говоря, каждая ветвь в Mercurial нуждается в своем собственном каталоге; в git вы обычно работаете в одном каталоге. Переключение ветвей в Mercurial означает изменение каталогов; в git это означает просить git изменить содержимое каталога с помощью git checkout.

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

Edit: как отметил Deestan, Hg имеет имени отделения, которые могут храниться в одном репозитории и позволяют разработчику переключать ветви в одной рабочей копии. ветви git не совсем такие же, как ветви Mercurial named, во всяком случае: они постоянны и не отбрасывают ветви, как в git. Это означает, что если вы используете ветку для экспериментальных задач даже если вы решите не слить его, он будет храниться в репозитории. Именно по этой причине Hg рекомендует использовать клоны для экспериментальных краткосрочных задач и именованные ветви для долгосрочных задач, например для ветвей выпуска.

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

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

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

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

Что это означает на практике? Ну, многие операции быстрее в git, такие как переключение на другой коммит, сравнение коммитов и т. д. Особенно если эти изменения далеко.

AFAIK нет никакого преимущества о приближении меркуриала.

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

другой возможной причиной выбора является приложение или служба, которая поддерживает только один из системы.. Например, я в значительной степени решил изучить git из-за github..

также сравнение google (хотя это немного старый, сделано в 2008 году)

http://code.google.com/p/support/wiki/DVCSAnalysis

если я правильно их понимаю (и я далек от эксперта по каждому), у каждого из них принципиально своя философия. Я впервые использовал mercurial в течение 9 месяцев. Теперь я использовал git для 6.

hg программное обеспечение контроля версий. Основная цель-отслеживать версии программного обеспечения.

git-это файловая система на основе времени. Его цель-добавить другое измерение в файловую систему. У большинства есть файлы и папки, git добавляет время. Что это происходит, чтобы работать awesome как 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 против 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 с помощью clone

$ 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 фактически такой же, как git-new-workdir. Оба они делают совершенно новый рабочий dir почти так, как если бы вы набрали 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)

теперь работать над одним я просто do

git checkout fix-game-save-bug

и начать работать. Совершать поступки и т. д. Переключение между ветвями даже в таком большом проекте, как chrome, происходит почти мгновенно. Я на самом деле не знаю, как это сделать в hg. Это не часть учебников, которые я читал.

одна большая разница. Этап в Git.

у Git есть эта идея сцены. Вы можете думать об этом как о скрытой папке. Когда вы фиксируете, вы фиксируете только то, что находится на сцене, а не изменения в вашем рабочем дереве. Это может звучит странно. Если вы хотите зафиксировать все изменения в своем рабочем дереве, вы должны сделать git commit -a, который добавляет все измененные файлы на сцену, а затем нарушает их.

в чем тогда смысл сцены? Вы можете легко отделить свои коммиты. Представьте, что вы редактировали джойстика.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 даже имеет команды, чтобы решить, какие конкретные строки в том же файле вы хотите скопировать на сцену, чтобы вы могли разделить их совершает отдельно, а также. Зачем тебе это нужно? Потому что как отдельные коммиты другие могут вытащить только те, которые они хотят, или если была проблема, они могут вернуть только коммит, у которого была проблема.

в versioncontrolblog есть динамическая диаграмма сравнения, где вы можете сравнить несколько разных систем управления версиями.

Вот таблица сравнения между git, hg и bzr.

есть довольно существенные различия, когда дело доходит до работы с филиалами (особенно краткосрочными).

Это объясняется в эта статья (BranchingExplained) который сравнивает Mercurial с Git.

есть ли в вашем проекте сотрудники на базе Windows?

потому что, если есть, Git-для-Windows GUI кажется неудобным, сложным, недружелюбным.

Mercurial-on-Windows, напротив, не является сложным.

одна вещь, котор нужно заметить между mercurial bitbucket.org и git of github, mercurial может иметь столько частных репозиториев, сколько вы хотите, но github вам нужно обновить до платной учетной записи. Итак, вот почему я иду на bitbucket, который использует mercurial.

в прошлом году я оценил git и hg для собственного использования и решил пойти с hg. Я чувствовал, что это выглядело как более чистое решение и лучше работало на большем количестве платформ в то время. Но в основном это был бросок вверх.

совсем недавно я начал использовать git из-за git-svn и способности действовать как клиент Subversion. Это меня покорило, и теперь я полностью переключился на git. Я думаю, что у него немного более высокая кривая обучения (особенно, если вам нужно совать нутро), но это действительно отличная система. Я собираюсь прочитать те две сравнительные статьи, которые Джон опубликовал сейчас.

в настоящее время я в процессе перехода от SVN к DVCS (в то время как блоги о моих выводах, мои первые реальные усилия в блогах...), и я провел небольшое исследование (=googling). Насколько я вижу, вы можете сделать большинство вещей с обоими пакетами. Похоже, что git имеет несколько больше или лучше реализованных дополнительных функций, Я чувствую, что интеграция с windows немного лучше для mercurial, с TortoiseHg. Я знаю, что есть Git Cheetah (я пробовал оба), но mercurial решение просто чувствует себя более надежным.

видя, как они оба с открытым исходным кодом (правильно?) Я не думаю, что будет отсутствовать важные функции. Если что-то важно, люди будут просить об этом, люди будут кодировать это.

Я думаю, что для общей практики, Git и Mercurial более чем достаточно. У них обоих есть большие проекты, которые их используют (git - > ядро linux, Mercurial - > проекты Mozilla foundation, оба среди других, конечно), поэтому я не думаю, что они действительно чего-то не хватает.

Это, как говорится, мне интересно, что другие люди говорят об этом, так как это было бы отличным источником для моих усилий в блогах ;-)

есть большие и исчерпывающие таблицы сравнения и диаграммы на git, Mercurial и Bazaar на руководство InfoQ о DVCS.

Я понимаю, что это не часть ответа, но на этой ноте я также думаю, что доступность стабильных плагинов для таких платформ, как NetBeans и Eclipse, играет роль в том, какой инструмент лучше подходит для задачи, или, скорее, какой инструмент лучше всего подходит для "вас". То есть, если вы действительно хотите сделать это CLI-way.

Как Eclipse (и все на его основе), так и NetBeans иногда имеют проблемы с удаленными файловыми системами (например, SSH) и внешними обновлениями файлов; это еще одна причина, по которой вы хотите, чтобы все, что вы выбираете, работало "плавно".

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

еще одно интересное сравнение mercurial и git:Mercurial vs Git. Основное внимание уделяется внутренним органам и их влиянию на процесс ветвления.

Если вас интересует сравнение производительности Mercurial и Git, посмотрите на в этой статье. Вывод:

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

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

Если вы переходите из SVN, используйте Mercurial, так как его синтаксис гораздо более понятен для пользователей SVN. Кроме этого, ты не можешь ошибиться ни в том, ни в другом. Но проверьте ГИТ учебник и HGinit перед выбором одного из них.

эта ссылка может помочь вам понять разницу http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

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

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

любой профессиональный инструмент должен иметь четко разработанный и интуитивно понятный CLI. Пользователи Mercurial могут выполнять большую часть работы, выдавая простые команды без каких-либо странных опций. В Git double dash сумасшедшие варианты являются нормой. Mercurial имеет существенное преимущество, если вы человек CLI (и, честно говоря, любой уважающий себя инженер-программист должен быть).

приведу пример, предположим, что вы совершите ошибку. Вы забыли отредактировать некоторые файлы. Чтобы отменить действие в Mercurial, просто введите:

$ hg rollback

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

в Git вы должны ввести:

$ git reset --soft HEAD^

Итак, предположим, у вас есть представление о том, что такое сброс. Но кроме того, вы должны знать, что такое "- мягкие" и "- жесткие" сброса (любые интуитивные догадки?). О, и, конечно, не забывайте о характере" ^ в конце концов! (во имя Ричи, что это?..)

интеграция Mercurial с сторонними инструментами, такими как kdiff3 и meld, намного лучше. Создавайте свои патчи объединяйте свои ветви без особой суеты. Mercurial также включает простой http-сервер, который вы активируете, введя

hg serve

и пусть другие просматривают ваш репозиторий.

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