Я использую git в течение некоторого времени в Windows (с помощью msysGit), и мне нравится идея распределенного контроля источника. Совсем недавно я смотрел Mercurial (hg), и это выглядит интересно. Тем не менее, я не могу обернуть голову вокруг различий между hg и git.
Кто-нибудь сделал сравнение бок о бок между 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, так как он чувствует себя чистым и элегантным - меня отложили с помощью сценариев оболочки /Perl/Ruby, которые я получил с помощью Git. Попробуйте взглянуть на git-instaweb.sh file, если вы хотите знать, что я имею в виду: это shell script, который генерирует Ruby script, который, я думаю, запускает веб-сервер. Оболочка script создает еще одну оболочку script для запуска первого Ruby script. Для хорошей меры также существует немного Perl.
Мне нравится сообщение в котором сравниваются Mercurial и Git с James Bond и MacGyver - Mercurial как-то более сдержанно, чем Git. Мне кажется, что люди, использующие Mercurial, не так легко впечатляют. Это отражено в том, как каждая система делает то, что Линус описывает как "самое крутое объединение EVER!" . В 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 будет отменен иначе, когда вы вытащите из несвязанного репозитория. Именно такие различия делают Меркуриал более элегантным для меня.
Git - платформа, Mercurial - это просто приложение. Git - это платформа с версией файловой системы, которая поставляется с приложением DVCS в поле, но, как обычно, для приложений платформы, она более сложна и имеет более грубые края, чем приложения с ориентированными приложениями. Но это также означает, что git s VCS чрезвычайно гибкий, и существует огромная глубина вещей, не связанных с источником, которые вы можете сделать с помощью git.
В этом суть разницы.
Git лучше всего понять с нуля - из формата репозитория вверх. Скотт Чаконс Git Обсуждение - отличный пример для этого. Если вы попытаетесь использовать 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 и перезапускать его, и я не использую файловую систему каждый раз, когда я ввожу.
Изменить: как отметил Deestan, Hg имеет имена ветвей, которые могут быть сохранены в одном репозитории и позволяют разработчику переключаться между ветвями внутри одной и той же рабочей копии. git ветки не совсем такие же, как и Mercurial, называемые ветвями, во всяком случае: они являются перманентными и не отбрасывают ветки, как в git. Это означает, что если вы используете именованную ветку для экспериментальных задач, даже если вы решили никогда не объединять ее, она будет храниться в репозитории. Именно поэтому Hg рекомендует использовать клоны для экспериментальных, коротких задач и названных ветвей для длительных задач, например для ветвей выпуска.
Причина, по которой многие пользователи HG предпочитают клоны над названной ветвью, гораздо более социальны или культурны, чем технические. Например, с последними версиями Hg можно даже закрыть именованную ветвь и рекурсивно удалить метаданные из наборов изменений.
С другой стороны, git приглашает использовать "названные ветки", которые не являются постоянными и не хранятся в метаданных в каждом наборе изменений.
С моей личной точки зрения, модель git глубоко связана с понятием названных ветвей и переключается между веткой и другой с той же самой директорией; hg может делать то же самое с именованными ветвями, но при этом поощряет использование клонов, что мне лично не нравится слишком много.
Существует одна огромная разница между git и mercurial; способ представления каждого из них. git представляет собой фиксацию в виде снимков, в то время как mercurial представляет их как diff.
Что это значит на практике? Ну, многие операции быстрее в git, например, переход на другой фиксатор, сравнение коммитов и т.д. Особенно если эти коммиты находятся далеко.
AFAIK нет преимуществ от меркуриального подхода.
Ничего. Они оба делают то же самое, оба выступают одинаково. Единственная причина, по которой вы должны выбрать один над другим, - это помочь вам в проекте, который уже использует его.
Другая возможная причина выбора одного - это приложение или услуга, которая поддерживает только одну из систем. Например, я довольно много решил изучить 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
И теперь в 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 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 ветки, каждая из которых основана на ветке, называемой мастером. (Я уверен, что есть какой-то способ в git, чтобы сделать эти 1 строку каждый вместо 2)
Теперь, чтобы работать над одним, я просто делаю
git checkout fix-game-save-bug
и начать работать. Commit things и т.д. Переключение между ветвями даже в проекте размером с хром почти мгновенно. На самом деле я не знаю, как это сделать в hg. Это не часть учебных пособий, которые я прочитал.
Еще одна большая разница. git.
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 даже имеет команды, чтобы решить, какие строки в том же файле вы хотите скопировать на сцену, чтобы вы могли разделить эти коммиты отдельно. Почему вы хотите это сделать? Поскольку в качестве отдельных коммитов другие могут вытащить только те, которые они хотят, или если возникла проблема, они могут вернуть только коммит, у которого возникла проблема.
В редакторе versioncontrolblog имеется динамическая сравнительная диаграмма, где вы можете сравнить несколько различных систем управления версиями.
Существуют значительные различия в работе с веткими (особенно краткосрочными).
В этой статье (BranchingExplained), которая сравнивает Mercurial с Git.
Есть ли в вашем проекте сторонники Windows?
Потому что, если есть, графический интерфейс Git -for-Windows кажется неудобным, трудным, недружественным.
Mercurial-on-Windows, напротив, без проблем.
Одно замечание между mercurial bitbucket.org и git github заключается в том, что у mercurial может быть столько частных репозиториев, сколько вам нужно, но github вам нужно перейти на платный аккаунт. Итак, почему я иду на битбакет, который использует меркурий.
Когда-то в прошлом году я оценил как git, так и hg для собственного использования, и решил пойти с hg. Я чувствовал, что это похоже на более чистое решение, и в то время работало лучше на других платформах. Тем не менее, это было главным образом.
Совсем недавно я начал использовать git из-за git -svn и способности действовать как клиент Subversion. Это выиграло меня, и теперь я полностью переключился на git. Я думаю, что он получил немного более высокую кривую обучения (особенно, если вам нужно совать вокруг себя), но это действительно отличная система. Я собираюсь прочитать эти две сравнительные статьи, которые Джон опубликовал сейчас.
В настоящее время я перехожу из SVN в DVCS (в то время как блоги о моих выводах, о моих первых действиях в блогах...), и я провел небольшое исследование (= googling). Насколько я вижу, вы можете делать большинство вещей с обоими пакетами. Кажется, что git имеет несколько более или более совершенных расширенных функций, Я чувствую, что интеграция с окнами немного лучше для mercurial, с TortoiseHg. Я знаю там git Cheetah (я попробовал оба), но меркурийное решение просто чувствует себя более надежным.
Увидев, что они оба с открытым исходным кодом (правда?), я не думаю, что у вас не будет важных функций. Если что-то важно, люди будут просить об этом, люди будут его кодировать.
Я думаю, что для обычных практик git и Mercurial более чем достаточны. У них обоих есть большие проекты, которые их используют (Git → linux kernel, Mercurial → проекты Mozilla, как, среди прочих, конечно), поэтому я не думаю, что на самом деле чего-то не хватает.
Мне кажется, что меня интересуют, что говорят другие люди, поскольку это станет отличным источником для моих усилий в блогах: -)
Есть большие и исчерпывающие таблицы сравнения и графики на git, Mercurial и Bazaar в Руководство по InfoQ о DVCS.
Я понимаю, что это не часть ответа, но в этой заметке я также считаю, что доступность стабильных плагинов для таких платформ, как NetBeans и Eclipse, играет роль в том, какой инструмент лучше подходит для задачи, или, скорее, какой инструмент лучше всего подходит для вас. То есть, если вы действительно хотите сделать это CLI-способом.
Оба Eclipse (и все на их основе) и NetBeans иногда имеют проблемы с удаленными файловыми системами (такими как SSH) и внешними обновлениями файлов; что является еще одной причиной, по которой вы хотите, чтобы все, что вы решили работать "без проблем".
Я тоже пытаюсь ответить на этот вопрос для себя тоже.. и я сварил кандидатов на Git или Mercurial.. спасибо всем вам за полезный вклад в эту тему, не обращаясь к религиозным.
Еще одно интересное сравнение меркуриальных и git: Mercurial vs Git. Основное внимание уделяется внутренним воздействиям и их влиянию на процесс ветвления.
Если вы заинтересованы в сравнении производительности Mercurial и Git, посмотрите в этой статье. Вывод:
Git, а Mercurial оба хороши, но делают интересный компромисс между скоростью и размером репозитория. Mercurial быстро сочетается с добавлением и модификациями и одновременно контролирует рост хранилища. Git также быстро, но его репозиторий быстро растет с измененными файлами, пока вы не переупакуете - и эти репаки могут быть очень медленными. Но упакованное хранилище намного меньше, чем Mercurial's.
На сайте Mercurial есть отличное описание сходств и различий между двумя системами, объясняя различия в словаре и базовых концепциях. Как долгое время пользователь git, это действительно помогло мне понять ментуриальное мышление.
Если вы переходите из SVN, используйте Mercurial, поскольку его синтаксис является более понятным для пользователей SVN. Кроме этого, вы тоже не ошибетесь. Но проверьте GIT учебник и HGinit перед выбрав один из них.
Эта ссылка может помочь вам понять разницу http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Некоторые считают, что системы VCS должны быть сложными. Они поощряют изобретение терминов и концепций на местах. Вероятно, они подумают, что многочисленные кандидаты на эту тему будут интересны. Среди них, вероятно, те, которые разработали Git.
Mercurial спроектирован с другим менталитетом. Разработчики не должны заботиться о VCS, и вместо этого они должны тратить свое время на свою основную функцию: разработка программного обеспечения. Mercurial позволяет пользователям использовать и радостно злоупотреблять системой, не позволяя им совершать какие-либо неисправимые ошибки.
Любой профессиональный инструмент должен иметь четко разработанный и интуитивно понятный интерфейс командной строки. Пользователи Mercurial могут выполнять большую часть работы, выдавая простые команды без каких-либо странных опций. В Git двойной тире сумасшедшие варианты являются нормой. Mercurial имеет существенное преимущество, если вы человек CLI (и, честно говоря, любой уважающий себя Инженер-программист должен быть).
Чтобы привести пример, предположим, что вы совершили ошибку по ошибке. Вы забыли отредактировать некоторые файлы. Чтобы отменить действие в Mercurial, просто введите:
$ hg rollback
Затем вы получите сообщение о том, что система отменяет вашу последнюю транзакцию.
В Git вам нужно ввести:
$ git reset --soft HEAD^
Итак, предположим, у вас есть идея, о чем reset. Но, кроме того, вы должны знать, что сбрасываются "--soft" и "--hard" (любые интуитивные догадки?). О, и, конечно же, не забывайте символ "^" в конце! (теперь то, что в Ритчи это имя...)
Меркурийная интеграция с сторонними инструментами, такими как kdiff3 и meld, намного лучше. Сгенерируйте свои патчи, чтобы объединить свои ветки без особых проблем. Mercurial также включает простой HTTP-сервер, который вы активируете, набрав
hg serve
И пусть другие просматривают ваш репозиторий.
Суть в том, что Git делает то, что Mercurial делает, гораздо более сложным способом и с гораздо более низким уровнем CLI. Используйте Git, если вы хотите превратить VCS вашего проекта в научную область. Используйте Mercurial, если вы хотите получить работу VCS, не заботясь об этом, и сосредоточьтесь на своих реальных задачах.