Я уже некоторое время использую git в Windows (с msysGit), и мне нравится идея распределенного управления исходным кодом. Совсем недавно я смотрел на Mercurial (HG), и это выглядит интересно. Тем не менее, я не могу обернуть голову вокруг различий между ртутью и мерзавцем.
Кто-нибудь делал параллельное сравнение между git и hg? Мне интересно знать, чем отличаются hg и 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флаг to hg pull, который необходим, так как Mercurial будет прерывать иначе, когда вы извлекаете из несвязанного репозитория. Именно такие различия делают Mercurial более элегантным для меня.
git pull <url-of-project>. письмо, которое вы цитировали, относится к самым ранним дням работы git (2005)
Git - это платформа, Mercurial - «просто» приложение. Git - это версионная платформа файловой системы, которая поставляется с приложением DVCS в комплекте, но, как обычно для приложений платформы, она более сложна и имеет более грубые края, чем специализированные приложения. Но это также означает, что VCS git чрезвычайно гибок, и есть огромная глубина вещей, не связанных с управлением исходным кодом, которые вы можете делать с git.
В этом суть разницы.
Git лучше всего понимается с нуля - от формата хранилища до. Git Talk Скотта Чакона - отличный учебник для этого. Если вы попытаетесь использовать git, не зная, что происходит под капотом, в какой-то момент вы будете в замешательстве (если вы не будете придерживаться только самых базовых функций). Это может показаться глупым, когда все, что вам нужно, это DVCS для вашей повседневной программы, но гениальность git заключается в том, что формат репозитория на самом деле очень прост, и вы можете легко понять всю работу git.
Для некоторых сравнений, ориентированных на техническую специфику, лучшими статьями, которые я лично видел, были Дастин Саллингс:
Он на самом деле широко использовал обе DVCS и хорошо их понимает - и в итоге предпочел 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 многие операции выполняются быстрее, например переключение на другой коммит, сравнение коммитов и т. Д. Особенно, если эти коммиты находятся далеко.
AFAIK, нет никакого преимущества подхода Mercurial.
Ничего. Они оба делают то же самое, оба работают примерно одинаково. Единственная причина, по которой вы должны выбрать один, а другой - если вы помогаете с проектом, который уже использует один ..
Другая возможная причина выбора - приложение или служба, которая поддерживает только одну из систем. Например, я в значительной степени выбрал изучение git из-за github .
Также сравнение 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 может это делать, и часто люди используют его таким образом, который не применяется. 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 даже есть команды, чтобы решить, какие именно строки в одном и том же файле вы хотите скопировать на сцену, чтобы вы также могли разделить эти коммиты по отдельности. Почему вы хотите это сделать? Поскольку в качестве отдельных коммитов другие могут извлекать только те, которые им нужны, или, если возникла проблема, они могут отменить только тот коммит, который имел проблему.
git add --patchсмотрите linux.die.net/man/1/git-add или используйте git add -i, как в stackoverflow.com/questions/2372583/…
checkout -b <name>вы можете просто использовать git branch <name>для создания новой ветки, не переключаясь на нее
В файле versioncontrolblog есть таблица динамического сравнения, где вы можете сравнить несколько разных систем контроля версий.
dir-a/foo.cв dir-b/foo.cи продолжать работать над dir-b/foo.c, то ваша работа над dir-a/foo.cбудет правильно сливались с моей работой после рывка.
Существуют довольно существенные различия в работе с филиалами (особенно кратковременными).
Это объясняется в этой статье (BranchingExplained), которая сравнивает Mercurial с Git.
Есть ли в вашем проекте соавторы на базе Windows?
Потому что, если есть, графический интерфейс Git-for-Windows кажется неловким, трудным, недружественным.
Mercurial-on-Windows, напротив, не представляет никакой сложности.
Когда-то в прошлом году я оценил и git, и hg для собственного использования, и решил пойти с hg. Я чувствовал, что это выглядело как более чистое решение, и в то время работало лучше на большем количестве платформ. Хотя, в основном, это были проблемы.
Совсем недавно я начал использовать git из-за git-svn и способности выступать в качестве клиента Subversion. Это покорило меня, и теперь я полностью переключился на мерзавца. Я думаю, что у него немного более высокая кривая обучения (особенно если вам нужно разбираться с внутренностями), но это действительно отличная система. Я собираюсь прочитать эти две сравнительные статьи, которые Джон разместил сейчас.
В настоящее время я нахожусь в процессе перехода от SVN к DVCS (в то время как веду блог о моих результатах, о моих первых реальных усилиях по ведению блога ...), и я провел небольшое исследование (= поиск в Google). Насколько я вижу, вы можете делать большинство вещей с обоими пакетами. Похоже, в git реализовано несколько или более улучшенных расширенных функций, я чувствую, что интеграция с windows немного лучше для Mercurial, с TortoiseHg. Я знаю, что есть и Git Cheetah (я пробовал оба), но ртутное решение кажется более надежным.
Видя, как они оба с открытым исходным кодом (верно?), Я не думаю, что ни у кого из них не будет важных функций. Если что-то важно, люди будут просить об этом, люди будут кодировать это.
Я думаю, что для обычных практик Git и Mercurial более чем достаточно. У них обоих есть большие проекты, которые используют их (Git -> ядро linux, Mercurial -> проекты Mozilla Foundation, конечно же, оба среди других), так что я не думаю, что им чего-то действительно не хватает.
При этом мне интересно, что другие люди говорят по этому поводу, так как это послужило бы отличным источником для моих усилий по ведению блога ;-)
В руководстве InfoQ по DVCS есть отличные и исчерпывающие сравнительные таблицы и диаграммы по git, Mercurial и Bazaar .
Я понимаю, что это не часть ответа, но на этом замечании, я также думаю, что наличие стабильных плагинов для платформ, таких как 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/git-mercurial-and-bazaar-a-comparison/
Некоторые люди думают, что системы 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, не заботясь об этом, и сосредоточиться на своих реальных задачах.