Я вже деякий час використовую git у Windows (з msysGit), і мені подобається ідея розподіленого керування джерелами. Зовсім недавно я дивився на Mercurial (hg), і це виглядає цікаво. Однак я не можу обернути голову навколо відмінностей між hg та git.
Хтось робив побічне порівняння між git та hg? Мені цікаво дізнатися, чим відрізняються hg і git без необхідності стрибати у фан-дискусії.
Відповіді:
Ці статті можуть допомогти:
Редагувати : порівнювати Git та Mercurial зі знаменитостями здається тенденцією. Ось ще один:
Я працюю над Mercurial, але принципово вважаю, що обидві системи рівноцінні. Вони обидва працюють з однаковими абстракціями: серія знімків (наборів змін), які складають історію. Кожен набір змін знає, звідки він (батьківський набір змін) і може мати безліч наборів змін. Нещодавнє розширення hg-git забезпечує двосторонній міст між Меркуріалом та Git і щось подібне показує цю точку.
Git має сильний акцент на мутації цього графіка історії (з усіма наслідками, що тягне за собою), тоді як Mercurial не заохочує переписувати історію, але все одно це легко зробити, і наслідки цього - саме те, що ви повинні очікувати від них (тобто , якщо я зміню набір змін, який у вас уже є, ваш клієнт буде бачити його як новий, якщо ви вийдете з мене). Тож Меркуріал має упередженість до неруйнівних команд.
Що стосується легких гілок, то Mercurial підтримує сховища з декількома гілками з…, я завжди думаю. Репозиторії Git з кількома гілками - це саме те, що: кілька розбіжних напрямків розвитку в одному сховищі. Потім Git додає імена до цих ниток і дозволяє запитувати ці назви віддалено. Розширення « Закладки» для Mercurial додає локальні назви, і за допомогою Mercurial 1.6 ви можете переміщати ці закладки, коли ви натискаєте / тягнете ..
Я використовую Linux, але, мабуть, TortoiseHg швидше і краще, ніж еквівалент Git в Windows (через краще використання поганої файлової системи Windows). І http://github.com, і http://bitbucket.org надають Інтернет-хостинг, сервіс у Bitbucket чудовий і чуйний (я не пробував github).
Я вибрав Mercurial, оскільки він відчуває себе чистою та елегантною - мене відклали сценарії оболонки / 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 скасує інакше, коли ви вийдете з неспорідненого сховища. Такі відмінності змушують Меркуріал здаватися мені більш елегантним.
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 предпочитають клонування над названою галуззю, є набагато більш соціальною чи культурною, ніж технічною. Наприклад, з останніми версіями Hg навіть можливо закрити названу гілку та рекурсивно видалити метадані із наборів змін.
З іншого боку, git пропонує використовувати "названі гілки", які не є постійними і не зберігаються як метадані на кожному наборі змін.
З моєї особистої точки зору, то модель git глибоко пов'язана з концепцією названих гілок і перемикання між гілкою та іншою за допомогою одного і того ж каталогу; hg може зробити те ж саме з названими гілками, але все ж це заохочує використання клонів, що особисто мені не дуже подобається.
Є одна величезна різниця між git та mercurial ; те, як представляють кожну комісію. 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 може це зробити, і часто люди використовують це таким чином, який не застосовується. Гіт-картина, якщо є така річ, може легко виглядати так
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
Насправді в чомусь навіть не має сенсу показувати гілки в git.
Одне, що дуже заплутано для обговорення, git та 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 клон насправді те саме, що 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
і почати працювати. Здійснюйте завдання тощо. Перемикання між гілками навіть у проекті такого великого, як хром, майже миттєве. Я насправді не знаю, як це зробити в hg. Це не частина навчальних посібників, які я читав.
Ще одна велика різниця. Етап Гіта.
У Гіта є ця ідея сцени. Ви можете думати про це як про приховану папку. Виконуючи зобов'язання, ви здійснюєте лише те, що на сцені, а не зміни у вашому робочому дереві. Це може здатися дивним. Якщо ви хочете здійснити всі зміни у вашому робочому дереві, ви зробите це, 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>для створення нової гілки без переходу на неї
На диспетчері версій існує динамічна схема порівняння, де можна порівняти кілька різних систем управління версіями.
dir-a/foo.cв dir-b/foo.cі продовжувати працювати над dir-b/foo.c, то ваша робота над dir-a/foo.cбуде правильно зливалися з моєю роботою після ривка.
Існують досить суттєві відмінності, що стосуються роботи з галузями (особливо короткострокових).
Це пояснюється в цій статті (BranchingExplained), яка порівнює Mercurial з Git.
Чи є у вашому проекті співавтори на базі Windows?
Тому що, якщо вони є, графічний інтерфейс Git-for-Windows здається незручним, важким, недружелюбним.
Mercurial-на Windows, навпаки, не є мозком.
Колись минулого року я оцінив як git, так і hg для власного використання, і вирішив піти з hg. Я відчував, що це виглядає як більш чисте рішення, і я працював краще на більшій кількості платформ у той час. Це, в основному, підкидання.
Зовсім недавно я почав використовувати git через git-svn та здатність виступати в ролі клієнта Subversion. Це мене перемогло, і я тепер повністю перейшов на git. Я думаю, що це дещо вища крива навчання (особливо, якщо вам потрібно розіграти нутрощі), але це дійсно чудова система. Я збираюся прочитати ці дві статті порівняння, які Джон опублікував зараз.
Наразі я перебуваю в процесі переходу зі SVN на DVCS (в той час як веду блоги про свої висновки, мої перші реальні зусилля щодо ведення блогів ...), і я трохи провів дослідження (= гуглінг). Наскільки я бачу, ви можете робити більшість речей з обома пакетами. Схоже, що git має ще кілька або краще реалізованих розширених функцій, я відчуваю, що інтеграція з Windows трохи краща для меркуріалу, з TortoiseHg. Я знаю, що є і Git Cheetah (я спробував і те, і інше), але приналежне рішення просто відчуває себе більш надійним.
Бачачи, як вони обидва з відкритим кодом (правда?), Я не думаю, що жодним із них не бракує важливих функцій. Якщо щось важливе, люди просять про це, люди це кодують.
Я думаю, що для загальних практик, Git і Mercurial більш ніж достатньо. У них обох є великі проекти, які їх використовують (Git -> Linux Linux, Mercurial -> Mozilla Foundation проекти, і те, і інше, звичайно), тож я не думаю, що і в них насправді чогось не вистачає.
Зважаючи на це, мені цікаво, що говорять про це інші люди, оскільки це могло б стати чудовим джерелом для моїх зусиль щодо ведення блогів ;-)
Існує чудова та вичерпна таблиця порівняння та діаграми щодо git, Mercurial та Bazaar у посібнику InfoQ про DVCS .
Я усвідомлюю, що це не є частиною відповіді, але, маючи на увазі, я також вважаю, що наявність стабільних плагінів для таких платформ, як NetBeans та Eclipse, грає роль, в якій інструмент краще підходить для виконання завдання, а точніше, який інструмент найкраще підходить для "ти". Тобто, якщо ви дійсно не хочете робити це за допомогою CLI.
І Eclipse (і все, що базується на ньому), і NetBeans іноді мають проблеми з віддаленими файловими системами (наприклад, SSH) та зовнішніми оновленнями файлів; це ще одна причина, чому ви хочете, щоб все, що завгодно, працювало «безперешкодно».
Я намагаюся зараз відповісти на це питання і сам. Я зголосив кандидатів до Git чи Mercurial .. дякую всім за те, що ви надали корисні матеріали з цієї теми, не релігійні.
Ще одне цікаве порівняння меркуріалу і git: Mercurial vs Git . Основна увага приділяється внутрішнім і їх впливу на процес розгалуження.
Якщо вас цікавить порівняння продуктивності Mercurial та Git, ознайомтеся з цією статтею . Висновок такий:
І Git, і Mercurial отримують хорошу кількість, але роблять цікавий компроміс між швидкістю та розміром сховища. Mercurial швидкий як з доповненнями, так і з модифікаціями, і одночасно тримає під контролем зростання сховищ. Git також швидкий, але його сховище зростає дуже швидко із зміненими файлами, поки ви не перезавантажуєтесь - і ці перепакування можуть бути дуже повільними. Але запакований сховище набагато менше, ніж у Mercurial.
Веб-сайт mercurial має чудовий опис подібності та відмінності між двома системами, пояснюючи відмінності словникового запасу та основні поняття. Як давно користувач git, він справді допоміг моєму розумові розуму Меркуріалу.
Якщо ви переходите з SVN, використовуйте Mercurial, оскільки його синтаксис набагато зрозуміліший для користувачів SVN. Крім цього, ви не можете помилитися ні з одним. Але перевірте підручник з GIT та HGinit, перш ніж вибрати один із них.
Це посилання може допомогти вам зрозуміти різницю http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Деякі люди вважають, що системи VCS мають бути складними. Вони заохочують вигадувати терміни та поняття на місцях. Вони, напевно, подумають, що численні кандидати наук з цього питання будуть цікавими. Серед них, мабуть, ті, які сконструювали Git.
Меркуріал розроблений з іншим менталітетом. Розробники не повинні дуже піклуватися про VCS, і вони повинні замість цього витрачати свій час на свою головну функцію: інженерія програмного забезпечення. Mercurial дозволяє користувачам використовувати та радісно зловживати системою, не дозволяючи їм робити помилки, які не підлягають відшкодуванню.
Будь-який професійний інструмент повинен мати чітко розроблений та інтуїтивний CLI. Користувачі Mercurial можуть виконати більшу частину роботи, видаючи прості команди без будь-яких дивних параметрів. У Git подвійний тире, шалені варіанти - це норма. Mercurial має істотну перевагу, якщо ви людина CLI (і, чесно кажучи, будь-який поважаючий себе інженер-програміст повинен бути).
Щоб навести приклад, припустимо, ви робите вчинення помилково. Ви забули редагувати деякі файли. Щоб скасувати дію в Mercurial, просто введіть:
$ hg rollback
Потім ви отримуєте повідомлення про те, що система скасовує вашу останню транзакцію.
У Git потрібно ввести:
$ git reset --soft HEAD^
Так гаразд, припустимо, ви маєте уявлення про те, про що йде скидання. Але крім того, ви повинні знати, що таке "--soft" та "--hard" скидання (якісь інтуїтивні здогадки?). О, і звичайно, не забудьте символ "^" врешті-решт! (тепер, що в ім'я Річі - це те, що ...)
Інтеграція Mercurial із сторонніми інструментами, такими як kdiff3 та meld, також значно краща. Створіть свої патчі, зробіть свої гілки без особливої суєти. Mercurial також включає простий http-сервер, який ви активуєте, ввівши
hg serve
І дозвольте іншим переглядати ваше сховище.
Суть полягає в тому, що Git робить те, що робить Mercurial, набагато складнішим чином і з набагато нижчим CLI. Використовуйте Git, якщо ви хочете перетворити СКС свого проекту в науково-дослідницьку сферу. Використовуйте Mercurial, якщо ви хочете виконати роботу з VCS, не піклуючись про це, і зосередьтеся на своїх реальних завданнях.