Почему Git получил так много шумихи? ... а другие нет? [закрыто]

124

В последние годы ажиотаж вокруг Git сильно возрос. Все знают о Git, никто не знает об альтернативах.

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

Цель этого поста - попытаться лучше понять это явление.

Как получается, что Git получает всю часть пирога? Они как-то использовали лучший маркетинг? Это потому, что его сообщество более ... хм ... "многословно"? Это из-за имени "Линус"? Это из-за его вызывающего образа?

Каково ваше мнение?

оборота арно
источник
63
Возможно, вы правы в том, что Линус Торвальдс является единственной причиной его популярности ...
Роберт Коритник
4
Я не знаю, я чувствую, что они были выставлены мне примерно в равных количествах ... хотя я слышал о мерзавце до hg. Но да, Торвальдс - знаменитость, поэтому все, чем он занимается, может привлечь внимание.
преступник
13
Мне нравится GitHub ... вот и все
Cnd
7
@jrwren, я предскажу этот комментарий, сказав, что я не использовал ни Git, ни Mercurial. Если бы я изучал Git, а затем сразу изучил Mercurial (или наоборот), один из них, скорее всего, занял бы у меня меньше времени на изучение. Тот, который занял меньше времени, - тот, который я бы посчитал более простым в использовании. Гроккинг обычно подразумевает, что требуется некоторое время, чтобы понять, что для этого труднее использовать. Я не говорю, что это ухудшит качество продукта, иногда требуется более крутая кривая обучения для более мощных инструментов, но это, безусловно, меняет простоту использования.
zzzzBov
8
@MarkTrapp Боже, Марк! Похоже, у всех была хорошая дискуссия, а потом вам пришлось прийти и всех вывести за дверь. Хотелось бы, чтобы я знал о таком сайте, как StackOverflow, который позволял вести обсуждения.
Теодор Р. Смит

Ответы:

86

Я считаю, что такие сервисы, как GitHub или Gitorious, имеют большое значение. Для людей важно, чтобы они могли где-то размещать свои вещи, и особенно GitHub - отличный сервис для этого.

Для Mercurial не было такого сервиса, когда DVCS стал популярным (по крайней мере, я не знал об этом). Теперь у вас есть Bitbucket и, возможно, другие, но GitHub существует уже довольно давно, он хорошо известен и становится все лучше и лучше.

daaawx
источник
Добавьте к этому, что некоторые огромные проекты с открытым исходным кодом используют git, который принимает решение за вас. Меня «заставляли» использовать git несколько раз (например, для Android), но я не был вынужден использовать Mercurial или Bazaar. Кроме того, я думаю, что Git это здорово :)
FeatureCreep
11
Есть также Google Code и SourceForge для hg
конфигуратор
7
Git усилен Github, который помещает другие хранилища в тень. Bitbucket имеет некоторые преимущества (бесплатные частные репозитории), но пользовательский интерфейс оставляет желать лучшего по сравнению с Github
iandotkelly
2
Я использую Mercurial для общения с GitHub ... плагин hggit ( hg-git.github.com ) позволяет отделить инструмент от сообщества. Но, возможно, не из инструментов сообщества.
bpanulla
1
CodePlex также поддерживает Mercurial.
Грант Пэйлин
86

Я вижу много ответов на этот вопрос, которые основаны на чувствах, которые испытывал автор, когда слышал о том или ином СКМ. Другие говорят, что все это была чистая удача. Я верю, что удача прослеживается в истории.

Я буду говорить об истории.

Git и Mercurial были созданы одновременно, чтобы решить одну и ту же проблему. В те дни ядро ​​Linux было вынуждено прекратить использовать BitKeeper , проприетарную распределенную SCM, которую он использовал в течение 3 лет. Причиной этого было то, что Ларри Маквой, генеральный директор BitMover, компании, стоящей за BitKeeper, прекратил раздачу своего программного обеспечения бесплатно для разработчиков Linux, потому что кто-то из сообщества Linux перепроектировал его.

Линус Торвальдс, недовольный тем, что уже существовало, впоследствии начал работать над новым SCM, который он скоро назовет Git. Вскоре после этого Мэтт Маккалл начал проект Mercurial по тем же причинам.

Спустя некоторое время, разрабатывая эти проекты по отдельности, Мэтт Маккалл представил расширенную версию своего SCM и определенным образом сравнил ее с Git (самому которому всего пара недель). Линус решил использовать его вместо Git для разработки ядра, но отказался от этой идеи, когда понял, что Mercurial использует Changesets для регистрации изменений редакции . Он боялся, что это слишком близко к тому, как работает BitKeeper, и он определенно не хотел ничего, что могло бы заставить кого-то сказать: «Они создали клон BitKeeper».

Поэтому Git использовался для разработки ядра вместо Mercurial, но оба они были технически актуальны. Конечным результатом является то, что Git начал с того, что его фактически использовали там, где он был предназначен для использования, в то время как Mercurial не так быстро нашел свое первое большое применение FOSS. Поскольку он был наделен очень хорошим дизайном, и благодаря настойчивости Мэтта Маккалла, он в конечном итоге стал знаменитым и привык к большим, реальным проектам.

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

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

Bazaar - это еще один SCM, который очень известен в мире GNU, но не настолько за его пределами, потому что он был построен с целью удовлетворения сообщества GNU. Программное обеспечение часто идет туда, куда его создатели хотят, и не дальше.

С другой стороны, распределенные СКМ - явные победители. Я не вижу много широко используемых нераспределенных SCM.

Thaddee Tyl
источник
5
Я действительно ценю эту историю.
Jrwren
4
@ TMN Ты прав! Фактически, когда всплыл обратный инжиниринг Эндрю Триджелла, и когда Ларри Маквой изменил лицензирование BitKeeper, было так много пламенных войн, что Линус Торвальдс решил отказаться от него и дал себе неделю, чтобы найти замену. В то время настоящим конкурентом был Monotone, но это было медленно. Многие люди создавали замены одновременно, и все были просто счастливы использовать новые инструменты. Я думаю, что Git сначала ударил 1.0, затем Mercurial; Базар занял почти два года.
Тэдди Тил
7
«Я не вижу много широко используемых нераспределенных SCM». Это зависит от того, где вы находитесь в отрасли. Perforce, ClearCase и svn по-прежнему очень широко используются, но не так много (за исключением svn) в мире открытого исходного кода. О да, и Visual Source Safe, и MS Team в магазинах Windows.
Боб Мерфи
13
Под «обратным инжинирингом» вы подразумеваете телнетирование на сервер и ввод «help»
альтернатива
3
Я бы сказал это в целом о DVCS и CVCS: «Все программное обеспечение участвует в Дао и не должно подвергаться пренебрежению». "Включая программное обеспечение от Redmond?" «О, черт возьми, посмотрите на часы. Класс уволен».
Боб Мерфи
77

Линус Торвальдс

Линус - большой сторонник Git и много лет продвигал его основной группе Linux, и он вырос оттуда. Полагаю, это полностью связано с влиянием Линуса на сообщество * nix.

Лично я до сих пор использую Subversion, но это от предпочтений, а не от полезности.

Джастин Шилд
источник
12
Я не думаю, что это лично Линус, а огромная известность Linux - Есть несколько вещей, которые вы могли бы сказать кому-то, у кого нет предварительных знаний о DVCS (или даже о разработке программного обеспечения в целом), с большей вероятностью, чтобы придать доверие, чем «это используется для Ядро Linux ".
Майкл Боргвардт
6
Мало того, что он большой сторонник этого - он тот, кто создал оригинальные версии этого, прежде чем он передал его Хунио Хамано
Марко Чеппи
44
Какая? Почему вы предпочитаете Subversion?
конфигуратор
11
Разве вы не имеете в виду, что вы все еще используете Subversion по привычке и по инерции, а не по предпочтению или из-за полезности? Вот почему я все еще использую его, и я подозреваю, что большинство из нас тоже тоже ...
Коди Грей
7
@deadalnix: потому что Linux и Linux имеют множество кричащих фанатов, не имеющих аналогов ни в одном другом проекте с открытым исходным кодом. Они функционируют как довольно эффективная уличная команда для Git.
Том Андерсон
34

Обычная проблема в системе контроля версий - объединение веток .

Вам нужно попробовать его, когда он не работает, чтобы понять, насколько это может быть больно и насколько важно работать, чтобы свободно работать с ветками.

Узнав, что Линус Торвальдс написал git, чтобы сделать это правильно, и что якобы в одной ситуации он использовал git для объединения двенадцати веток одновременно, это очень убедительный аргумент для того, чтобы git был интересным.

Около года назад я находился в ситуации, когда мне приходилось выбирать между hg и git, и слияние выше было одним из важных факторов при выборе git. Во-вторых, организация Eclipse перешла на git, поэтому ожидалось, что инструментарий Eclipse будет полезен для проектов Java. С выпуском Eclipse 3.7 это произошло. Мы были, возможно, на 6-9 месяцев раньше.

Для разных нужд hg может быть таким же полезным. Sun выбрала его для своей VCS на основе очень тщательного расследования. Возможно, вы захотите найти официальные документы и выяснить их обоснование.


РЕДАКТИРОВАТЬ: Обратите внимание, я не говорю, что Mercurial не может ничего сделать, только для Java с Eclipse - что является нашей главной целью - рыночные силы в настоящее время наиболее сильны для git, даже под Windows, и мы должны стоять на плечах других, а не их ног.

user1249
источник
5
+1 Это все в ветках. Этот анализ обсуждает объединяющую силу Git по сравнению с Mercurial.
Амелио Васкес-Рейна
19
@AmV: Пожалуйста, не публикуйте запутанные URL.
Коди Грей
4
Я не уверен, что вижу вашу точку зрения здесь. Вы говорите, что они одинаково хороши в ветвлении (Git не делает ничего, чего не может делать Mercurial), но поскольку вам нужно хорошее ветвление, вы выбрали Git?
Джалф
8
Я никогда не видел убедительных примеров того, как Git лучше объединяется, чем Mercurial, и, конечно, нет в этом ответе. Как будто вы путаете Hg с SVN или CVS.
Ааронаут
23

Вместо того, чтобы говорить, почему git или mercurial лучше, и говорить, что это единственная причина его популярности, я собираюсь сосредоточиться на сообществе.

Как я подчеркивал ранее , сообщество Git очень громкое и высокомерное. Большинство будет энергично защищать свою драгоценную программу. Большинство войн против Git против Mercurial, которые я видел, были начаты людьми, которые задавались вопросом, почему все на Земле не используют святого мерзавца. Сайты, такие как whygitisbetterthanx.com, даже демонстрируют это высокомерие во введении, которое написано для приманки пламени других.

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


В отличие от других сообществ DVCS не так громко. Я не знал, что Mercurial существует, пока не увидел «Какой лучший DVCS?» вопрос по ТАК. В то время как git появляется везде, другие DVCS находят время, чтобы найти.

TheLQ
источник
16
Разве не называть других высокомерными?
21
@ Thorbjørn: Это так. За исключением случаев, когда я это делаю; тогда это просто правильно.
Том Андерсон
6
Я думаю, что у вас аллергия на мерзавца. Я прочитал введение WhyGitisBetterthanx и некоторые его содержание. Я не вижу ничего высокомерного или провокационного. Это просто нормальное предубеждение, которое имеет все, что предназначено для продвижения чего-либо.
back2dos
5
@ back2dos: это довольно высокомерно, так как утверждает, что «Git лучше всего». И в этом довольно большие фрагменты его аргументирующей аргументации либо неверны и не исправлены, либо вычеркнуты, и все же это как-то никогда не меняет их заключение.
Джалф
5
@Agos: И почти все из которых не являются уникальными для Git. Они просто перемещают стойку ворот , чтобы исключить другие продукты.
Ааронаут
14

Я не думаю, что Mercurial является особенно сдержанным. Kiln построен на Hg, и в последнее время была хорошая поддержка в таких IDE, как Eclipse & Netbeans.

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

Вы также пропускаете «Базар», который является настоящим «забытым DVCS».

Конечно, я согласен с тем, что Линус очень харизматичный парень и альфа-ботаник, почти не имеющий себе равных, поэтому многие люди тяготеют к Git из-за этого. Кроме того, «миф о творении» Git очень убедителен, так как Линус в течение 6 дней работал над созданием Git и опирался на седьмой - или что-то в этом роде. Когда у продукта есть запоминающаяся история, легче набрать обороты.

mcottle
источник
6
... полностью согласен с «Базаром», который является настоящим «забытым DVCS».
Дагналии
согласен, но воздействие hg от печи / джоэла более недавнее, чем у git воздействия от линуса. HG играет в догонялки
.
2
На самом деле существует довольно много «забытых DVCS», хотя многие из них, вероятно, лучше описать как «низкопрофильные», «сфокусированные» или «нишевые».
Джон Гейнс-младший
13

Это скромное мнение, но Git может получить всю эту рекламу из-за двух параметров:

  1. Это очень эффективно
  2. Это весело использовать (в некотором роде очень специфическим способом для компьютерных специалистов)

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

Тибо Дж
источник
4
1. Ртутный неэффективен в некоторой области? На самом деле, в течение долгого времени, он был более эффективным по сравнению с http, поэтому код Google включал его более 2 лет, по сравнению с поддержкой git, которая была анонсирована на прошлой неделе и только недавно стала одинаково полезной для http. 2. ОК 3. Есть эквивалент bitbucket.org
dagnelies
1
Я сказал, что ртутный был неэффективен? Я никогда не использовал это, так что я могу сказать.
Тибо Дж
4
это вообще не решает вопрос imho, по крайней мере, часть «в то время как другие этого не сделали»
jk.
1
Mercurial не может добавить «пустые папки» в репозиторий (не знаю, если это было исправлено сейчас), но когда мне пришлось выбирать DVCS, я в конечном итоге пошел Git для этой цели. Мне нужно было несколько пустых папок.
Мартин Маркончини
4
@ MartínMarconcini Что вы подразумеваете под "я в конце концов пошел Git для этой цели"? Git также не поддерживает пустые папки.
Макс Нанаси
12

Здесь работают три фактора: «бета гик медиа», «настало время» и «следуй за лидером»

Beta Geek Media

Есть ряд каналов, которые обсуждают "отвратительные действия". Они, конечно, будут охватывать появление новой системы контроля версий, но они охватывают git больше. Почему? Поскольку Линус Торвальдс написал это изначально, публично спорил об этом и использовал это как решение своей широко разрекламированной проблемы с bitkeeper. По сути, в любое время, когда на lkml идет пламенная война, бета-медиа-гики напишут статью об этом. Git обсуждение началось на lkml, поэтому он получил больше освещения, чем другие альтернативы. И бета-фанаты, которые читают slashdot, как будто это Variety, съели его. Конечным результатом этого является то, что у git в десять раз больше статей, чем у mercurial.

Время пришло

Большие проекты с открытым исходным кодом с большим количеством участников имеют проблемы с централизованным управлением исходным кодом. По мере роста открытого исходного кода и увеличения вероятности того, что в проектах появилось много участников, проблема усугубляется. Linux, вероятно, самый известный проект, страдающий от этого, но есть много других. Поскольку многие проекты достигли этой точки, потребовалась какая-то продвинутая VCS. Git, Mercurial и Bazaar были большими победителями здесь. Арч и Монотоне были слишком рано и пропустили волну шумихи.

Следуйте за лидером

У больших проектов есть последователи, которые регулярно проверяют и создают код, даже если они не вносят свой вклад. Последователи знакомятся с инструментами, необходимыми для получения проекта, которому они следуют, поэтому эти инструменты получают большее использование. Давайте посмотрим на проекты «большой ничьей» для трех больших DVCS:

  • Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
  • Mercurial : Java, Mozilla, Python
  • Базар : Ubuntu, Emacs

Git использует больше проектов "большого дро", поэтому больше людей знакомы с git, написано больше уроков по git.

Шон Макмиллан
источник
1
Возможно, вы правы, но ваш список «большой ничьи» немного вводит в заблуждение / предвзятость. Глядя на сайт Bazaar, они перечисляют немало других крупных проектов: MySQL, Bugzilla, Debian, GNU кажутся довольно широко известными. Список Hg также немного больше.
Джалф
@jalf: такой список должен быть субъективным. Я собрал свой собственный Linux и Gnome, но не Mozilla или Emacs. Другие могут быть прямо противоположным способом. Вопрос на самом деле "сколько людей вытащат этот проект из системы контроля версий"? Я перечислил те, которые, как мне кажется, наиболее вероятно, вдохновляют людей на установку vcs для извлечения текущего источника.
Шон Макмиллан
Справедливо. Я предположил, что это была попытка составить объективный список (в конце концов, списки основных проектов, использующих каждую систему
DVCS,
12

В основном это просто самообман. Git является самым популярным, поэтому он получает наибольшую известность, что делает его более популярным.

Git, Hg и Bzr - все совершенно хорошие системы DVCS, но пугающее число людей приравнивает DVCS к Git и считает, что все прелестные функции DVCS уникальны для Git. И поэтому они используют Git, рекомендуют Git и говорят такие вещи, как «Git лучше, потому что он может выполнять слияния осьминогов» (как и базар), или «Git лучше, потому что он распространяется» (как и любой DVCS, отсюда и название ), или «Git лучше, потому что это облегчает ветвление и слияние» (опять же, это верно для каждой DVCS).

К сожалению, потому что я чувствую, что альтернативы тоже могут предложить многое, и я бы предпочел, чтобы люди выбрали Git за его уникальные преимущества, а не просто потому, что они думают, что DVCS == Git.

Когда кто-то обнаруживает, насколько умны DVCS, указывая на одну конкретную DVCS, он часто не идет и не говорит другим: «Эй, DVCS отличные, вы должны их использовать», а скорее «DVCS, который я узнал о DVCS'ах - это здорово, вы должны его использовать ".

оборота Джалф
источник
11

Github. Github является пионером в социальном кодировании. Он превратил контроль версий в социальную платформу, которая привлекла большое внимание и, очевидно, просто поддерживает Git. Социальные медиа = большее принятие. Bitbucket набирает обороты, хотя и получает много новых функций, что делает его вероятным конкурентом :)

DelvarWorld
источник
7

Ну, на самом деле я думаю, что шумиха связана со всеми DSVC вместе.

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

Я подозреваю, что Mercurial будет широко использоваться, конечно, так же часто, как и git, может быть, больше (Microsoft и другие крупные компании используют его сейчас), но люди, использующие Mercurial, чаще всего просто хотели DSVC, который они могли бы быстро понять, а не то, на чем могла бы основываться религия. Таким образом, они менее вокальны и более активны в обсуждениях, чем активные, как некоторые пользователи git.

Безусловно, о базаре много не говорят, потому что его используют лишь несколько крупных известных проектов, и ни одна крупная компания, кроме Canonical, не использует его. Сравните, например, с Google (git, mercurial, svn) и большими проектами с открытым исходным кодом, и вы поймете, почему об этом не говорится. Fossil - еще один продукт, который интересен нише разработчиков, поэтому я думаю, что это нормально и хорошо, когда о них слышат только те, кто ищет функции, которые они предоставляют (например, встроенную вики, отслеживание ошибок и форум).

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

Кроме того, Google Code Hosting и SourceForge теперь позволяют использовать как git, так и mercurial, поэтому он становится более специфичным для проекта, чем раньше, когда вы выбрали git из-за функций GitHub.

Там нет настоящей войны, просто интересное разнообразие инструментов.

Klaim
источник
Я бы хотел, чтобы реклама была в целом о DVCS, но из всего, что я видел, эта реклама была о Git, и большинство людей думают, что DVCS и Git - это одно и то же.
Джалф
6

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

Я использовал Базар почти с тех пор, как он был создан для разных вещей. Самым большим, что я использовал для этого, был проект AllTray, для которого я (в настоящее время) единственный разработчик и сопровождающий. Базар это хорошо. Это просто работает, это не мешает мне, и мне почти никогда не приходится просматривать страницу --help или страницу руководства для этого. Тем не менее, есть некоторые недостатки этого:

  1. Большая функциональность, которая, возможно, должна быть частью ядра VCS, не является таковой. Такие вещи, как возможность делить пополам историю, выполнять длинный вывод через пейджер или иметь «совмещенные» ветки (например, репозитории в стиле git), поставляются в виде плагинов.
  2. Многие плагины не так уж стабильны. Например, функциональность colocated ветвей, кажется, не работает хорошо на стороне сервера (по крайней мере, я никогда не заставлял это работать, это имеет тенденцию выдавать ошибку, говоря, что ветвь в данном пути не существует, когда это прямо перед вами, и вы можете увидеть кровавую вещь).
  3. У него нет операции «клонирования», вы тянете ветки по одной за раз. Вам нужно проделать дополнительную работу, если вы хотите иметь репозиторий, чтобы вы могли эффективно извлекать новые ветви.
  4. Для некоторых проектов это мучительно медленно. Попробуйте «bzr branch lp: mysql» когда-нибудь.
  5. Ему не хватает сильной поддержки для крючков; Вы можете написать плагины bzr, которые предоставляют хуки, но не существует стандартного способа иметь произвольные скрипты хуков на стороне сервера.

Недавно я перешел на git для разработки AllTray, и очень быстро думаю о переносе всех моих проектов в git. Есть немного больше времени, затраченного на знакомство с канатами, но, похоже, оно того стоит. Некоторые вещи, которые я заметил:

  1. git clone это относительно быстрая операция, которая дает вам информацию обо всех ветвях, существующих в репозитории, который вы клонировали.
  2. Добавление дополнительных удаленных репозиториев безболезненно, поэтому вы можете отслеживать множество различных репозиториев, которые имеют несколько веток, если хотите.
  3. Pro Git книга доступна в Интернете и в различных форматах, в том числе для устройств чтения электронных книг, и это не трудно читать.
  4. Git кажется гораздо проще расширять, чем Bazaar, и вам не нужно использовать какой-то один конкретный API для этого. (NB: это как верх, так и минус.)
  5. В git встроена функция деления пополам, и я не могу не подчеркнуть полезность этой функции.
  6. GitHub довольно хорош.
  7. gitosisСистема также очень приятно. Я даже не уверен, как можно было бы реализовать это, кроме как плагин в Bazaar, и я не могу себе представить, что это будет настолько эффективным.

Короче говоря: я использовал bzr очень долгое время, но git быстро доказывает мне его удивительность.

Майкл Трауш
источник
5

Используя git, вы, как правило, всегда находитесь в одном и том же локальном каталоге, когда занимаетесь разработкой, и просто git checkout branchnameпереключаетесь между ветками (я все время использую «легкие» ветки функций, поэтому для меня это очень важная функция).

Глядя на документацию и руководства Mercurial, кажется, что предпочтительным способом работы с различными ветками разработки является создание новых репозиториев путем клонирования. Этот учебник является примером.

Я полагаю, что в Mercurial вы можете делать то же самое, что и в git, но по какой-то причине документация Mercurial (которую я прочитал) почти всегда показывает ветвление, создавая клон репозитория.

(Я использую git ежедневно. У меня мало опыта работы с Mercurial, я играл с ним и следовал нескольким учебникам)

codeape
источник
2
Я использовал «именованные» ветки все время в hg. Это поддерживает их хорошо. hg branch foo, а hg up fooпотом ... Клон для ветки имеет некоторые слабые стороны для обычной разработки.
Пол Натан
Хм, значит, вы говорите, что Git лучше, чем Hg, потому что, хотя Hg поддерживает функцию, которая вас интересует, сообщество Hg считает альтернативный подход превосходным?
Джалф
1
1: Мне интересно: почему акцент делается на «ветвление путем клонирования» в документации Hg (см., Например, hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html и mercurial.selenic. ком / руководство )? Мне просто кажется грязным иметь один репозиторий на ветку. 2: я не говорю, что git лучше, мой ответ - скорее наблюдение по вопросу, который для меня (новичка ртути) выглядит как различие между ними. Разница, кажется, скорее культурная, чем техническая, поскольку Hg также поддерживает «ветвление в одном и том же хранилище».
кодеап
3
Mercurial страдает от многих устаревших данных онлайн; многие из них были распространены людьми, которые используют git и не следили за обновлениями возможностей Mercurial. Большинство старых причин отдавать предпочтение клонированным репозиториям больше не применяются в современных версиях Mercurial (именованные ветки теперь могут быть закрыты, и есть система закладок, которая дает вам подобный шаблон использования для веток Git, если хотите).
Стивен М. Редд
4

Я не знаю, сколько таких рантов я видел за последние несколько недель, но все они, похоже, считают, что Mercurial и / или Bazaar объективно лучше, чем Git. Юзабилити, кажется, общая тема. Да, изучение Git было на удивление трудным после использования CVS и Subversion, но в этот момент я не хотел бы обменивать его на любые другие VCS, если он не представляет собой другой сдвиг парадигмы . И указание на таблицу функций очень мало расскажет мне о том, насколько она гибкая, расширяемая, безопасная или легкая . Например, по умолчанию git-diff используются цвета и пейджер. Конечно, я могу получить то же самое с diff ... | colordiff | less -Rчем-то, но должно быть очевидно, почему одно превосходит другое.

l0b0
источник
Я не думаю, что аргумент заключается в том, что вам следует переключаться - очевидно, использовать уже знакомый вам инструмент проще, чем переходить на другой, независимо от того, насколько легко этот другой. Я не думаю, что какой-либо сторонник DVCS мог бы действительно утверждать, что вы упускаете огромное количество, будучи на Git вместо Bazaar или Mercurial, между ними не так уж много.
ZoFreX
3

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

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

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

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

Я не думаю, что будет справедливо сказать, что git популярен только из-за обмана или поддержки Линуса. Вероятно, это объясняет то, что многие люди пробуют это, но они придерживаются этого и продвигают это, потому что это работает хорошо для них, чисто и просто.

Карл Билефельдт
источник
2

Разработка NetBSD использует CVS, и это все, что важно.

Джонатан Клайн IEEE
источник
2

У него более резкое, более содержательное имя, которое хорошо подходит для каламбуров.

Apophenia Overload
источник
1

Недавно я искал систему контроля версий для личных проектов, поэтому я просто попробовал их несколько. Я практически неграмотен в командной строке, и я слышал, что, хотя GUI были доступны, Git действительно предназначался для использования через командную строку, что сделало меня немного нерешительным. Честно говоря, это было нелепо легко подобрать, и я действительно наслаждаюсь этим. Документация является огромным фактором для принятия новой технологии, и у Git есть тонны смехотворно простой документации, которая понятна и доступна. Другие альтернативы, такие как SVN и Bazaar, были великолепны, они просто не делали это так просто, как Git. Github также является важным фактором, поскольку в настоящее время он стал настолько центральным для движения с открытым исходным кодом. Наличие (по иронии судьбы) централизованного расположения для обмена кодом и проектами само по себе меняет правила игры.

Морган Херлокер
источник
1

Просто мои 2 ¢ - я выбрал git вместо альтернатив, потому что он написан на C, а не на языке radtool или на слишком академическом языке высокого уровня. Преимущества в том, что это быстро и эффективно, и что я могу на самом деле использовать RTFS, если я сталкиваюсь с ошибками или поведением, которое я не могу объяснить. Это также позволяет использовать в крошечных автономных средах разработки, которые не включают в себя гигантские интерпретаторы / среды выполнения, что означает, что я могу напрямую извлекать из git-репозитория и компилировать в таких системах, вместо того, чтобы загружать последний источник в другом месте и rsync.

Р..
источник
1
По этой же причине я выбрал git, потому что он написан на скомпилированном языке, а не на python, и поэтому я могу просто иметь переносную версию git в своей ручке usb вместе с некоторыми другими инструментами.
Coyote21
И все же именно по этой причине Facebook выбрал вместо этого Mercurial: они не были довольны производительностью того или иного, но обнаружили, что было проще улучшить производительность Mercurial (которая для большинства операций была лишь на несколько процентов медленнее, чем мерзавец в целом) по signficant краю (что они и сделали путем интеграции со службой мониторинга файлов , так что мог бы сказать , что могло и не могло измениться, подробности см здесь ) из - за того , что питон было легче работать, чем С.
Жюль
1

Возможно, вам будет интересно узнать, почему проект рабочего стола GNOME выбрал git вместо hg и bzr, когда он решил перейти от svn несколько лет назад. Конечно, на этом пути было много горячих религиозных дискуссий, но на этой вики-странице GNOME кратко изложены плюсы и минусы, которые они применили к данному сообществу.

calum_b
источник
0

Не говоря уже о том, что Apple в настоящее время занимается распространением информации в целевом сообществе c. Если вы недавно создали новое приложение в Xcode 4, вы заметили, что оно автоматически спрашивает вас, хотите ли вы сделать Git-репо.

Предоставленный Xcode 4 существует всего несколько месяцев и не влияет на предыдущий успех Gits, но мы все знаем, как популярная Apple может делать вещи за короткое время.

tutts
источник
-1

Сейчас я переключаюсь с hg (kiln) на git (github). Я использовал печь около года прямо сейчас. Для меня ХГ не имеет недостатка. Я могу сделать все, что должен. Так что это здорово.

Почему я использую прямо сейчас?

На данный момент есть только три причины.

  1. GitHub предлагает великолепные суть
  2. GitHub предлагает отличные социальные функции
  3. Во время презентаций и семинаров для разработчиков я всегда публиковал свои образцы на hg и git. На git у меня примерно в 10 раз больше посетителей, чем на hg !!

Я думаю, что третий является наиболее важным.

Торстен

Торстен
источник
-2

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

Acaz
источник