Почему у Джита столько шумихи? а другие нет? [закрыто]

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

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

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

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

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

121 голос | спросил 2 revs
arnaud
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

23 ответа


86

Я считаю, что такие услуги, как http://www.github.com или http://www.gitorious.org - большой фактор. Для людей важно, чтобы они могли размещать свои вещи где-то, и особенно github - отличная услуга для этого.

В отношении меркуриона не было такой службы, когда dvcs стали популярными (по крайней мере, я не знал). Теперь у вас http://www.bitbucket.org и, возможно, другие, но github существует уже довольно долгое время, это хорошо известно и он становится все лучше и лучше.

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
81

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

Я расскажу об истории.

Git и Mercurial были созданы одновременно для решения одной и той же проблемы. Еще в те дни ядро ​​Linux было вынуждено покинуть период, в течение которого он использовал BitKeeper , собственный распределенный SCM, который хорошо обслуживал их в течение многих лет.

Действительно, Ларри МакВой, генеральный директор BitMover, компании, стоящей за BitKeeper, прекратил предоставление своего программного обеспечения бесплатно разработчикам Linux, потому что кто-то из сообщества Linux реконструировал его.

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

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

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

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

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
77

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

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

Лично я все еще использую Subversion, но это скорее предпочтение, чем полезность.

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
34

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

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

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

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

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


EDIT: Заметьте, я не говорю, что Mercurial ничего не может сделать, только для Java с Eclipse, который является нашим основным направлением - рыночные силы в настоящее время сильны для git даже под Windows, и нам нужно стоять на плечах других, а не на ногах.

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
23

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

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

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


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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
14

Я не думаю, что Mercurial - это особенно низкий профиль. Печь строится на Hg & была хорошая поддержка в IDE, таких как Eclipse & Сейчас Netbeans.

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
13

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
12

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

Средства массовой информации Beta Geek

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

Время правильное

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

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

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
12

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

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
11

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
7

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

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

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

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

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

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

Нет реальной войны, просто интересное множество инструментов.

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
6

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

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

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

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
5

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

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
4

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
3

Справедливости ради, я думаю, что сторонники git против mercurial немного и далеко друг от друга по сравнению с git против централизованных адвокатов. Однако причины легко подытожить:

  

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

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

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
2

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
2

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
1

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
1

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
1

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
0

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

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
-2

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

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19
-2

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

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

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

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

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

Торстен

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132