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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Я использовал Базар почти с тех пор, как он был создан для разных вещей. Самым большим, что я использовал для этого, был проект 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 быстро доказывает мне его удивительность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Торстен

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