Популярность Git/Mercurial/Bazaar против того, что рекомендовать
Учитывая количество вопросов на этих трех распределенных системах контроля версий на этом сайте, похоже, что Git либо
- является более популярным, или
- сложнее (следовательно, требует больше вопросов), или
- имеет больше возможностей (следовательно, требует больше вопросов).
Или, скорее всего, сочетание трех. (Допустим, популярность на этом сайте приравнивается к популярности в целом.) Вот цифры:
Неудовлетворительно иметь на выбор три конкурирующих, но в значительной степени эквивалентных продукта с открытым исходным кодом. Лично я использую Git, и я в порядке с двумя другими. Но когда дело доходит до рекомендации одной системы над другими, я хотел бы спросить: можем ли мы начать рекомендовать одну безопасную еще?
Комментарии с середины 2009 года. Недавняя историческая популярность Subversion четко отражена в количестве вопросов, указывающих, по крайней мере, на небольшое изменение шкалы в сторону Git над Mercurial или Bazaar.
Комментарии с середины 2010 года: посмотрите на это огромное относительное увеличение численности ртути. Очевидно, что только двух точек данных недостаточно, чтобы показать тенденцию, но похоже, что Git и Subversion в значительной степени укоренились, Mercurial значительно вырос, а Bazaar оставался относительно спокойным.
Краткий комментарий, середина 2011 года: можно ли назвать Git победителем? :) Нет, я принимаю аргумент, что количество вопросов не эквивалентно популярности. Числа, конечно, сильны, хотя.
Код для воспроизведения вышеуказанного сюжета:
import datetime as dt
import matplotlib.pyplot as plt
dates = [
"01/06/2009",
"01/07/2010",
"01/07/2011",
"01/07/2012",
"01/07/2013",
"01/07/2014",
"01/07/2015",
"01/07/2016",
"01/06/2017",
"28/08/2018",
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]
git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525]
mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765]
bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539]
ax = plt.gca()
ax.grid()
plt.plot(x, git, label="[git]")
plt.plot(x, svn, label="[svn]")
plt.plot(x, mercurial, label="[mercurial]")
plt.plot(x, bazaar, label="[bazaar]")
plt.gcf().autofmt_xdate()
plt.ylim(0)
plt.legend()
# plt.show()
plt.savefig("comparison.png", transparent=True, bbox_inches="tight")
11 ответов
Обновление ноября 2011 года:
Git теперь намного более зрелый по сравнению с 2009 годом:
- Теперь поддерживается интеллектуальный http, что означает, что вы можете предложить вашему клиенту протокол https для извлечения / клонирования и проталкивания, а аутентификация способна взаимодействовать с LDAP (важно для пользователя на предприятии)
- Теперь в Gitolite существует зрелый уровень авторизации, что означает, что вы можете обеспечить изоляцию для "конфиденциального" хранилища (опять же, важно для крупных компаний).
- Поддержка Windows, которая уже была в 2009 году, по-прежнему сильна, а TortoiseGit довольно стабильна
- Идет интеграция с IDE, такой как Eclipse (большинство проектов Eclipse сейчас находятся на GitHub)
Однако установка Git в централизованной среде не тривиальна:
См. " Распределенные системы контроля версий и предприятие - хорошее сочетание? "
Постоянно упускается один момент:
они разные по своей природе.
- SVN - это система REVISION (она хранит ветки и метки только через дешевое копирование! Поддержка слияния не очень эффективна) и является централизованной.
- Mercurial или базар являются FILE VCS (они хранят версии файлов) и распространяются.
Arne Babenhauserheide вносит поправки в Mercurial, указав, что модель истории Mercurial отслеживает изменения содержимого, а пути файлов повторно используются на уровне хранилища для оптимизации доступа к файловой системе. - Git, и это очень трудно понять, это CONTENT VCS (он хранит дельту контента, а не сам файл: два файла с одинаковым контентом будут сохранены только один раз)
Это означает:
- если у вас есть простой рабочий процесс слияния, в одном месте разработки придерживайтесь SVN
- если у вас есть несколько мест разработки, распределенная VCS более адаптирована.
- Если у вас сложный рабочий процесс слияния, любая современная VCS лучше, чем SVN, которая борется за то, чтобы хранить информацию о слиянии в нужных местах в течение многих лет. Затем это зависит от инструментов (например, у Mercurial более продвинутая поддержка Windows)
- если у вас есть в основном текстовый файл и не слишком большие двоичные файлы, Git отлично работает, если вы знаете его ограничения.
Учитывая количество вопросов на этих трех распределенных системах контроля версий на этом сайте, похоже, что Git либо
- является более популярным, или
- сложнее (следовательно, требует больше вопросов), или
- имеет больше возможностей (следовательно, требует больше вопросов).
О популярности SCM - см. Следующий вопрос Stackru: Доступна ли статистика популярности / использования для бесплатных систем RCS/SCM/VCS?, Здесь у нас есть вопросы, например, какой набор игнорируемых файлов использовать для конкретного типа проекта, которые не зависят от SCM, но задаются для Git (и используют тег 'git'), потому что это тот, кто задал вопрос.
О том, что Git сложнее (и поэтому у него больше вопросов по SO) - конечно, у Git более крутая кривая обучения. Он также использует несколько (вполне) уникальных концепций, таких как промежуточная область (индекс) или все равные ветви, которые ответственны за его мощность, но поначалу может быть трудно получить правильные ответы (особенно, если кто-то из других SCM), Кроме того, пользовательский интерфейс Git не полностью согласован (хотя и становится лучше), потому что он вырос, а не развился; который отвечает за его мощность, но может привести к неоптимальному пользовательскому интерфейсу.
О том, что Git имеет больше возможностей - вам нужно будет проверить, сколько вопросов SO о продвинутых / необычных возможностях Git. Однако вы должны знать, что проекты с открытым исходным кодом заимствуют идеи друг у друга или имеют схожие функции, разработанные независимо: одним из примеров может быть поиск ошибок путем деления (поиска) истории на коммит, который привел к ошибке, которая была (насколько я знаю) разработана сначала в Git, а затем реализованный в виде плагина в Bazaar, и сначала в качестве расширения и в настоящее время основной функциональности в Mercurial. Другой - интерактивный выбор фрагментов изменений для фиксации, вдохновленный поведением Дарка. Еще одной идеей будет пакет Git, заимствованный из аналогичной концепции в Mercurial.
Еще одной возможностью возникновения большего количества вопросов SO может быть отсутствие хорошей документации... хотя в настоящее время она становится лучше с Руководством пользователя Git (распространяется вместе с Git) и Git Community Book (находится на домашней странице Git). Тем не менее, существует постоянный мем о том, что Git имеет худшую документацию, чем, скажем, Subversion с ее управлением версиями с помощью Subversion (также известной как svnbook) и Mercurial: полное руководство (также известное как hg-book)... и люди не читают документация, прежде чем задавать вопрос о Stackru, иногда.
Неудовлетворительно иметь на выбор три конкурирующих, но в значительной степени эквивалентных продукта с открытым исходным кодом. Лично я использую Git, и я в порядке с двумя другими. Но когда дело доходит до рекомендации одной системы над другими, я хотел бы спросить: можем ли мы начать рекомендовать одну безопасную еще?
Что ж, Git и Mercurial были разработаны независимо друг от друга, начиная примерно с одного и того же времени, в ответ на прекращение бесплатной лицензии на BitKeeper для использования разработчиками ядра Linux в качестве замены. О Subversion не могло быть и речи как о централизованном SCM, с отсутствием поддержки (тогда) в ядре для отслеживания слияний; это сделало его совершенно непригодным для широко распространенной модели разработки ядра Linux. Базар был, вероятно, слишком медленным (по крайней мере, тогда), и немного на централизованной стороне (я полагаю).
Git более мощный (на мой взгляд), Mercurial более простой (по мнению людей) и немного более переносимый (Python); Git является сценарием и основан на модели данных, допускающей независимые повторные реализации (см., Например, JGit, git, написанный на Java), в то время как Mercurial имеет привязки Python для написания расширений и в значительной степени основан на API, позволяющем изменить базовый формат репозитория (revlog - revlog-ng)... но это только мое предположение. Они заполняют немного разные ниши.
Кроме того, разве выбор не считается хорошим? У нас есть KDE, и у нас есть GNOME и XFCE (и другие оконные менеджеры и окружения рабочего стола); у нас есть Emacs и Vim (и другие редакторы программистов); у нас есть основанные на rpm (например, Fedora Core, Mandriva, SuSE) и основанные на deb (Debian, Ubuntu) и основанные на tgz (Slackware) и исходные (Gentoo) дистрибутивы; у нас есть KWord, AbiWord и OpenOffice.org... и у нас есть Git, Mercurial и Bazaar.
Я использую и рекомендую Mercurial
- а не Subversion, потому что он поддерживает распределенную разработку. Я могу работать на нескольких машинах и делать коммиты локально. Вы не можете сделать это с Subversion, по крайней мере, без сальто, таких как дополнительные репозитории
- а не базар, потому что поддержка окон базара это... хорошо.
- а не мерзавец, потому что он а) проще в изучении и использовании и б) поддержка Windows намного лучше
По моему опыту, судя по количеству вопросов, заметно искажается сравнение с мерзавцем и против Mercurial. Причина двоякая:
Посмотри на
hg update --helpпротивgit checkout -hа такжеgit --help checkout, С Mercurial я редко находил вопросы, на которые нет ответа несколькими взглядамиhg help,Проверьте Mercurial Wiki - если вам нужна помощь, вы, вероятно, найдете ее там, включая множество подсказок и хитростей: http://mercurial-scm.org/wiki/TipsAndTricks
[ПРИМЕЧАНИЕ: С выпуском Subversion 1.7 первый абзац в моем ответе ниже устарел, поскольку Subversion теперь просто создает одну папку ".svn" в базовой папке, аналогично другим сейчас.]
Одним из преимуществ любого из трех по сравнению с Subversion является то, что он не создает эквивалент папки ".svn" в каждой папке проекта. Обычно просто есть один (".hg", ".bzr" или ".git") в базовой папке. Одно это может стать хорошей причиной для использования одного из них поверх SVN, даже если вы используете модель централизованного хранилища. (Помимо: на самом деле, я часто использую svk в качестве svn-клиента, когда использую svn-репозиторий только для этой функции (только в Linux, хотя svk не подходит для windows)).
Конечно, одно из преимуществ subversion - вам не нужно извлекать весь проект, если вам нужна только одна из его подпапок.
Canonical (Ubuntu) отслеживает использование пакетов программного обеспечения для своего дистрибутива, поэтому нет необходимости полагаться на количество выпусков Stack Exchange для измерения популярности. Однако, как отмечали другие, это только отслеживает пользователей Ubuntu, а Canonical (Ubuntu) использует и рекомендует bzr (пример смещения). Тем не менее...
2011 2011 2011
Package Aug 3 Sep 29 Dec 9 Change
------ ------ ------ ------ ------
git-core 3647 3402 3236 -11%
bzr 4975 5286 6070 +22%
mercurial 3411 3387 3461 +1%
Снижение голосов за пакет git-core заставляет меня думать, что я сделал что-то не так, как grepвыбрал неверное имя пакета из таблицы популярности Ubuntu. Или, может быть, даже это количество голосов связано с установкой, а не с фактическим использованием программного обеспечения.
Вот некоторые исторические данные для трендов. Я использовал <install> скорее, чем <vote> Статистика Ubuntu в этой таблице, но она показывает всплеск роста на Bazaar и Mercurial, начиная с 2011 года. Тем не менее, bzr был позади git в 2011 году, но последние статистические данные за 2011 год показывают, что он прошел git всего установленных экземпляров (на Ubuntu).
June Aug Dec Growth Oct Growth
2010 2011 2011 2013
---- ----- ---- ---- ------ ---- ------
git 94k 159k 171k 80% 165k -3.5%
bzr 52k 121k 135k 160% 170k 26.0%
hg 36k 68k 75k 110% 95k 26.7%
Discalaimer: я использовал bzr в Ubuntu до 2012 года, когда работал в командах, которые использовали git исключительно. Bzr хорошо работает со всеми другими VCS, что позволяет вам использовать согласованный, интуитивно понятный синтаксис командной строки bzr. Мой переход на git было по социальным, а не техническим причинам.
С момента появления социального кодирования с Git на GitHub, Git, похоже, привлекло много последователей.
Причина, по которой у git так много пользователей, заключается в том, что ядро Linux использует его, поэтому, если вы хотите заняться разработкой Linux, вы должны использовать git.
Поскольку в git вовлечено очень много людей, я бы рекомендовал использовать git просто из-за большей базы пользователей. На самом деле, цифры, которые вы показываете выше, являются явным признаком этого.
Что касается сложности, все управление версиями является сложным, особенно распределенного типа. SVN и CVS были не совсем легкими (по крайней мере для меня) на первый взгляд. Это только часть необходимой кривой обучения, чтобы привыкнуть к системе контроля версий.
РЕДАКТИРОВАТЬ: Так как вы добавили ссылку на подрывную деятельность, я решил обратиться к нему. Я думаю, что большинство людей будут использовать SVN, потому что он имеет все виды симпатичных интерфейсов GUI для него. В общем, люди ненавидят использовать командную строку, в том числе некоторые разработчики. Git обычно не очень хорошо работает на Windows (или, по крайней мере, не так легко). Поскольку многие люди в Windows, это убивает количество потенциальных пользователей.
Кроме того, я думаю, что концепции SVN немного легче понять, поскольку svn использует центральный репозиторий, а не распределенную систему. Проще понять: "Вот большая гора кода, пожалуйста, добавьте сюда свой код", чем "Вот какой-то код, мой может отличаться от его, его от нее, но вы можете добавить что-нибудь, если хотите".
На мой взгляд, в SVN настроена гораздо лучшая система документации. Документация git ориентирована на немного более высокий уровень знаний (о программе, а не об интеллекте программистов) и поэтому имеет смысл после того, как вы используете систему, но при первом запуске она выглядит просто как кучка гоблинов.
В целом, я думаю, что svn есть и всегда будет более распространенным, потому что его общие принципы работы легче понять, инструменты просты в использовании, и он имеет прекрасную поддержку для Windows.
Позвольте мне закончить с моими последними двумя центами и сказать, что я предпочитаю git, потому что я думаю, что он намного мощнее, чем любая другая система, которую я использовал. Восхождение на кривую обучения определенно окупается, как только вы начинаете лучше понимать программу.
Проверьте следующую ссылку на опрос на эту тему:
Я обычно не пишу, но..
Я пробовал git, bzr и несколько других, которые я забыл, и обнаружил, что у bzr есть одно очень и очень слабое место. Для больших файлов он настаивает на загрузке всего файла в память. Это создает проблемы для больших двоичных файлов.
Git был намного лучше в этом отношении. Что касается сложности. Я использую Git в Windows от Git Bash. Отлично работает и выучил менее чем за неделю (включая реальную работу и эксперименты с другими VCS)