Популярность Git / Mercurial / Bazaar против того, что рекомендовать [закрыто]

У меня была эта проблема, решение заключалось в том, чтобы посмотреть на график фиксации (используя gitk) и увидеть, что у меня было следующее:

*   commit I want to cherry-pick (x)
|\  
| * branch I want to cherry-pick to (y)
* | 
|/  
* common parent (x)

Теперь я понимаю, что хочу сделать

git cherry-pick -m 2 mycommitsha

Это связано с тем, что -m 1 будет сливаться на основе общего родителя, где слияние -m 2 основано на ветве y, то есть тот, который я хочу, чтобы выбрать cherry-pick.

141
задан 15 revs, 7 users 61% 27 May 2019 в 21:07
поделиться

8 ответов

Обновление, ноябрь 2011 г .:

Git теперь намного более зрелый по сравнению с 2009 г .:

  • Теперь поддерживается smart http , что означает, что вы можете предложить своему клиенту протокол https для извлечения / клонирования и отправки , при этом аутентификация может взаимодействовать с LDAP (важно для пользователя на предприятии)
  • Зрелый уровень авторизации теперь существует с Gitolite , что означает, что вы можете обеспечить изоляцию «конфиденциального» репозитория (опять же, что важно для крупных компаний).
  • Поддержка Windows, которая уже существовала в 2009 году, заключается в все еще идет сильный,и TortoiseGit довольно стабилен
  • Интеграция с IDE, например Eclipse, находится в процессе (большинство проектов Eclipse сейчас размещено на GitHub)

Однако установка Git в централизованной среде не является тривиальной:
не сам файл: два файла с одинаковым содержимым будут сохранены только один раз)

Это означает:

  • если у вас есть простой рабочий процесс слияния , в одном месте разработки, придерживайтесь SVN
  • , если у вас есть несколько мест разработки, распределенная VCS более адаптирована.
  • если у вас есть сложный рабочий процесс слияния , любая современная VCS лучше, чем SVN, которая изо всех сил пытается сохранить информацию о слиянии в нужных местах годами. Затем это зависит от инструментов (например, Mercurial имеет более продвинутую поддержку Windows)
  • , если у вас в основном текстовый файл, а не слишком большие двоичные файлы, Git отлично подходит, если вы знаете его пределы ].
116
ответ дан 1 August 2019 в 07:11
поделиться

Я использую и рекомендую mercurial

  • , а не Subversion, потому что он поддерживает распределенную разработку. Я могу работать на нескольких машинах и делать коммиты локально. Вы не можете сделать это с помощью Subversion, по крайней мере, без кувырков, таких как дополнительные репозитории
  • , а не bazaar, потому что поддержка окон bazaar ... ну.
  • , а не git, потому что это а) проще изучить и использовать и б) поддержка Windows намного лучше
20
ответ дан 1 August 2019 в 07:11
поделиться

С момента зарождения социального кодирования с помощью Git на GitHub , Git, похоже, привлек множество последователей.

7
ответ дан 1 August 2019 в 07:11
поделиться

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

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

Что касается сложности, то любой контроль версий затруднен, особенно распределенный. На первый взгляд, SVN и CVS были непростыми (по крайней мере для меня). Это лишь часть необходимого обучения, чтобы привыкнуть к системе контроля версий.

РЕДАКТИРОВАТЬ: Поскольку вы добавили ссылку на подрывную деятельность, я решил, что обращусь к ней. Я думаю, что большинство людей будет использовать svn, потому что для него есть всевозможные красивые графические интерфейсы. В целом, люди, в том числе и некоторые разработчики, ненавидят использовать командную строку. git обычно не очень хорошо работает и в Windows (или, по крайней мере, не так гладко). Поскольку многие люди используют Windows, это убивает количество потенциальных пользователей.

Кроме того, я думаю, что концепции SVN немного легче понять, поскольку svn использует центральный репозиторий, а не распределенную систему. Легче понять: «Вот большая гора кода, пожалуйста, добавьте сюда свой код», чем «Вот какой-то код, мой может отличаться от его, его от ее, но вы можете добавить что-нибудь, если хотите»

На мой взгляд, в svn установлена ​​гораздо лучшая система документации. Документация git ориентирована на немного более высокий уровень знаний (программы, а не интеллекта программистов) и поэтому имеет смысл после того, как вы используете систему, но при первом запуске она просто выглядит как набор gobbeldy-gook.

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

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

6
ответ дан 1 August 2019 в 07:11
поделиться

Интересная запись в блоге Эрика Синка обо всех них.

1
ответ дан 1 August 2019 в 07:11
поделиться

[ПРИМЕЧАНИЕ: с выпуском Subversion 1.7 первый абзац в моем ответе ниже устарел, поскольку теперь Subversion просто создает одну папку «.svn» в базовой папке, аналогично остальным сейчас.]

Одно из преимуществ любого из трех перед Subversion состоит в том, что он не создает эквивалент папки «.svn» в каждой папке проекта. Обычно в базовой папке есть только один («.hg», «.bzr» или «.git»). Одно это может быть хорошей причиной использовать один из них вместо svn, даже если вы используете модель централизованного репозитория. (В сторону: на самом деле, я часто использую svk в качестве своего svn-клиента при использовании репозитория svn только для этой функции (хотя только для Linux, svk не подходит для Windows)).

Конечно, один преимущество подрывной деятельности в том, что вы не делаете

14
ответ дан 1 August 2019 в 07:11
поделиться

Судя по количеству вопросов на этом сайте по этим трем распределенным системам управления версиями, кажется, что Git либо

  1. более популярен, либо
  2. сложнее (следовательно, требуется больше вопросы), или
  3. имеет больше функций (следовательно, требует больше вопросов).
  1. О SCM популярности - см. следующий вопрос на StackOverflow: Имеется ли статистика популярности / использования для Бесплатные системы RCS / SCM / VCS? . Здесь у нас есть вопросы, например, какой набор игнорируемых файлов использовать для конкретного типа проекта, которые не зависят от SCM, но запрашиваются для Git (и с использованием тега 'git'), потому что это то, что использует человек, задавший вопрос.

  2. О том, что Git более сложен (и, следовательно, у него больше вопросов по SO) - безусловно, у Git более крутая кривая обучения. Он также использует несколько (совершенно) уникальных концепций, таких как промежуточная область (индекс) или равенство всех ветвей, которые несут ответственность за его мощность, но может быть трудно понять сначала (особенно если один исходит из другого SCM) . Кроме того, пользовательский интерфейс Git не является полностью согласованным (хотя он становится лучше), потому что он был выращен, а не разработан; который отвечает за его мощность, но может привести к неоптимальному пользовательскому интерфейсу.

  3. О Git, имеющем больше функций - вам нужно будет проверить, сколько SO-вопросов касается расширенных / необычных функций Git. Однако вы должны знать, что проекты с открытым исходным кодом заимствуют идеи друг у друга или имеют аналогичные функции, разработанные независимо: одним из примеров может быть поиск ошибок путем разделения (поиска) истории для фиксации, которая привела к ошибке, которая была (насколько мне известно) разработана. сначала в Git, а затем реализован как плагин в Bazaar и первое расширение и в настоящее время основная функциональность в Mercurial. Другой вариант - интерактивный выбор фрагментов изменений для фиксации, вдохновленный поведением Darcs. Еще одна идея пакета Git, заимствованная из аналогичной концепции в Mercurial.

  4. Еще одной возможностью источника большего количества вопросов SO может быть отсутствие хорошей документации ... хотя в настоящее время ситуация улучшается с Руководство пользователя Git (распространяется с Git) и Книга сообщества Git (находится на домашней странице Git). Тем не менее существует постоянный мем о том, что у Git документация хуже, чем, скажем, у Subversion с его Контроль версий с Subversion (также известный как svnbook ) и Mercurial: Окончательное руководство (также известное как hg-book ) ... и люди иногда не читают документацию, прежде чем задать вопрос о StackOverflow.

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

47
ответ дан 1 August 2019 в 07:11
поделиться

По моему опыту, судя по количеству вопросов, сравнение с git и с Mercurial заметно искажает картину. Причина двоякая:

  1. Посмотрите на hg update --help в сравнении с git checkout -h и git --help checkout. С Mercurial я редко находил вопросы, на которые не давали ответа несколько взглядов на hg help.

  2. Загляните в Mercurial Wiki - если вам нужна помощь, вы, скорее всего, найдете ее там, включая множество советов и рекомендаций: http://mercurial-scm.org/wiki/TipsAndTricks

16
ответ дан 1 August 2019 в 07:11
поделиться