Git, Hg или Bzr - Что рекомендовать новому пользователю?

Ответ 1

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

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

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

Ответ 2

То, что вы считаете одним из Mercurial pros - ревизионной нумерацией, считается недостатком многих людей. И то, что вы считали git недостатком - область постановки; будучи сложной концепцией, считается многообещающей.

Так что это не так просто.

Но если вы спросите меня - Mercurial - это Джеймс Бонд, как назвал его один из блоггеров - это элегантный и более высокий уровень, чем git, по крайней мере, на поверхности. Плюс его команды очень похожи на команды subversion, поэтому новые пользователи, которые преобразуются svn, могут узнать Mercurial гораздо быстрее, чем git.

Ответ 3

Я не думаю, что ваши друзья заметят большую разницу с любым из трех VCS. Если он просто используется как простая резервная копия с небольшим количеством ветвлений (вероятно, без конфликтов), не имеет значения, какой инструмент они выбирают. Все три могут выполнять простые задачи, не требуя от пользователя каких-либо специальных материалов.

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

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

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

Еще один фактор при выборе инструмента для неопытных пользователей, особенно когда им это может не понадобиться, это может быть доступность некоторого простого графического интерфейса пользователя. Там может быть даже хорошая интеграция с их TeX-редактором, который заставит их выбрать один инструмент над другим.

Ответ 4

Рекомендовать тот, который вы знаете лучше всего. Если вы порекомендуете его своим знакомым, вы должны быть готовы сначала взломать ответы на свои вопросы. Mercurial, Git и Bazaar все велики и значительно превосходят ничто. Если они когда-либо находят недостаток, тогда они могут опробовать одного из других, но, честно говоря, для начала, "Machts nichts!"

Ответ 5

Я передам свой опыт работы с Git и Mercurial в обоих случаях, начиная с нуля.

Я решил переместить мою команду (5 лучших и дисциплинированных разработчиков, включая меня) из ClearCase (UCM, но все они использовали как базовые ClearCase, так и UCM в течение нескольких лет). Посмотрев на все 3 Mercurial, Git и Bazaar, я обосновался на Mercurial (сильно повлиял на PEP 374).

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

Мы использовали очень разветвленную разработку (с именем branch per task) - по сути унаследовали от того, как ClearCase работал, но мы обнаружили, что это хороший способ для работы команды (обратите внимание - a lot пользователей Hg не понравится эта стратегия ветвления). Разработчик будет работать над задачей и отправить ее кому-то для проверки. Если раньше рецензент просматривал и делал заметки и т.д. И отправлял их обратно оригинальному разработчику, с Mercurial мы обнаружили, что мы просто переключаем ветки, просматриваем, затем передаем автора и вносим изменения вместе в среду рецензента (парное программирование ) и передать их в одну и ту же именованную ветвь.

Все, общее время для всей команды, чтобы получить скорость (со мной как наставник, начиная с нуля) было около 2 недель.

Мой опыт работы с Git более поздний - я начал использовать его только 2 месяца назад (и поэтому уже имел значительный опыт работы с Mercurial). Тем не менее, я сделал, начал использовать его около 2 месяцев назад, и теперь я начинаю чувствовать себя совершенно комфортно. Самая большая вещь, которая делает меня неудобной с Git, заключается в том, что Git предполагает, что вы будете редактировать историю и сделать ее легкой. Я должен регулярно читать части справки/руководства Git, чтобы проверить, что я делаю "правильно". Я считаю, что локальная ветка + система удаленного отслеживания очень чужая и неинтуитивная, тогда как ветвление в Mercurial невероятно просто (чтобы узнать, где вы находитесь по сравнению с другим репо, просто спросите его).

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

Ответ 6

Мне нравится Mercurial. Я предвзятый. Мне также нравится Perforce, но он не так открыт.

Ответ 7

Теги на StackOverflow должны дать вам довольно хороший признак поддержки сообщества за ним. В настоящее время количество вопросов:

• Git: 5 789
• Mercurial: 1,845
• Базар: 188

Демонстрация этого в форме круговой диаграммы:

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

Я расскажу о некоторых из основных Git заключает в мой ответ на "Если разработчик всегда использует контроль версий" .

Кроме того, GitHub, который является действительно удивительным хостинговым сайтом Git, который, как и хороший Red, получает исключительно лучше с возрастом. Например, в их новом файловом браузере мне было отказано.

В целом, я определенно думаю, что новички должны использовать Git, потому что там больше сообщества людей, использующих его, GitHub использует его, и если они используют язык программирования Ruby, это фактически стандарт de facto.

Ответ 8

Git.

Мне очень нравится Mercurial, и это было мое знакомство с DVCS, но реальность такова, что Git становится отраслевым стандартом. Когда я говорю с друзьями о том, что они используют на работе, каждый использует Git для новых проектов, перенося существующие проекты на Git или желая, чтобы они могли использовать Git на работе, если они использовали его для личные проекты, но не могут заставить людей переключаться на работу. Никто никогда не говорит о Меркуриале или Базаре. Раньше я был единственным человеком, которого я знал, кто говорил Mercurial, но я вскочил на победителя Git, когда стало ясно, что профессиональные разработчики будут использовать в обозримом будущем. Люди все еще говорят о SVN и очень часто CVS, но это потому, что их проекты начались много лет назад, и они еще не мигрировали, никто не говорит об использовании их для новой разработки.

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

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