Какой DVCS (git или hg) легче программировать для студентов? [закрыто]

Немного контекста: я учусь на третьем курсе. Студенты делятся на команды по 4 человека. Почти все будут работать под Windows (кроме тех, кто работает на Linux). В рамках школьной программы мы скоро начнем работать над проектом для реального клиента, но я и другая команда задаемся вопросом, какой способ был бы наилучшим для обмена нашим кодом друг с другом.

Я работаю неполный рабочий день в течение 3 лет и имею большой опыт использования git и mercurial в различных проектах, поэтому у меня нет проблем с использованием одной или другой системы. Тем не менее, никто из моих товарищей по команде никогда не использовал систему контроля версий раньше. Есть также другая команда, которая пыталась использовать SVN, но имела серьезные проблемы и предпочла бы попробовать что-то еще, поэтому они спросили мое мнение.

Мои мысли: я слышал, что mercurial + TortoiseHg имеет лучшую интеграцию под окнами, но мне интересно, может ли концепция анонимных головок сбить их с толку, даже если я их объясню. С другой стороны, я считаю, что ветки git легче понять начинающим (четкое разделение работы для каждого программиста), но они не так хорошо работают в Windows.

Mercurial, без сомнения.

Это, конечно, субъективно и зависит от одного человека к другому, но общее мнение заключается в том, что Mercurial легче подхватить, особенно кому-то новичку в VCS или кому-то из одного из VCS старого поколения.

Очки в руке:

1. Mercurial был разработан с учетом Windows ; Git был портирован. Независимо от того, что кто-то пытался сказать мне, Git все еще второсортный гражданин в Windows. За последние несколько лет ситуация определенно улучшилась, но вы все еще видите много споров о том, почему что-то работает / не работает в Windows, как это было в * nix box. TortoiseHg работает очень хорошо, а реализации Visual Studio еще проще в использовании, не нарушая ваш рабочий процесс.

2. Если кто-то начинает дискуссию «Git становится более мощным после тебя ...», то он почти все это говорит. Для 95% пользователей Mercurial кажется более интуитивным. Начиная с отсутствия индекса, до его более интуитивных опций (переключатели опций являются связными), до его локальных номеров для коммитов вместо хэшей SHA1 (кто когда-либо думал, что хэши SHA1 удобны для пользователя ??!)

3. Ветви Mercurial не менее мощны, чем ветви Git. Пост с описанием некоторых отличий. Вернуться к какой-то предыдущей ревизии так же просто, как «обновить старую ревизию». Начиная оттуда; просто сделай новый коммит. Именованные ветви также доступны, если вы хотите их использовать.

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

Просто отметить; Я использую Git и Mercurial ежедневно. Не беспокойтесь, используя любой из них. Но когда кто-то просит у меня рекомендации, я всегда рекомендую Mercurial. До сих пор помню, когда он впервые попал в мои руки, он был очень интуитивным. По моему опыту, Mercurial просто производит меньше WTF / мин, чем Git.

Я обнаружил, что пользовательский интерфейс TortoiseHg отлично подходит для Windows. В прошлом, когда я экспериментировал с Git, я вместо этого перешел к командной строке. Для обычного пользователя хороший пользовательский интерфейс гораздо более доступен, чем командная строка. Итак, я бы предложил использовать Mercurial. (Он также включает в себя хороший граф ветвления в окне рабочей среды. Он должен устранить любые основные трудности ветвления.)

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

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

Используйте fossil uiдля запуска временного веб-сервера, где бы вы ни находились, чтобы ваши коллеги-студенты синхронизировали вас. Он также предоставляет вам систему тикетов, вики и простой в использовании веб-интерфейс для смены веток и коммитов.

Просто убедитесь, что они читают краткое руководство и / или книгу . Наконец, существует проект под названием winFossil, который предоставляет им более дружественный пользовательский интерфейс, чем веб-интерфейс.

Учитывая, что команды являются новичками в управлении версиями, и многие используют Windows, я бы порекомендовал Mercurial Over Git.

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

На мой взгляд, Mercurial проще для новых пользователей, чтобы учиться. Это делает простые вещи легкими, а опасные трудными. Git делает опасные операции легкими (легко сделать, не обязательно легко сделать правильно!).

Интерфейс TortoiseHg для Winodows также очень хорош и является еще одним аргументом в пользу использования Mercurial.

Мое личное предпочтение - это мерзавец.

Однако, поскольку некоторые люди будут использовать Windows и существует превосходное руководство по hginit , я бы порекомендовал обучить их ртути.

Как полагают многие, Mercurial через TortoiseHg имеет очень низкий барьер для входа.

Для тех, кто работает в Windows, это один установщик, а не два (и целый набор вещей, о которых они, возможно, не захотят узнать), а пользовательский интерфейс THg гораздо лучше, чем TortoiseGit + Msysgit .

Анонимные головы

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

Именованные ветви

Одна вещь , которую я действительно не хватает в gitэто hg«s названные ветви , так что это один вариант. gitветки хороши, когда вы работаете над ними, но как только вы объедините эту работу с другой веткой, вы потеряете большую часть контекста для этих изменений.

В hgвас может создать ветку под названием Jira#1234и всегда быть в состоянии найти все ревизии , связанные с этим исправлением . После того git, как ваша ветвь объединена и ссылка удалена, вы должны определить, какие ревизии были частью исправления из топологии дерева ревизий. Даже если вы не удалите ссылку, вы все равно будете знать только последний коммит в этой ветке, а не то, кто из его предков был частью этой цепочки коммитов.

закладки

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

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

Index / Cache / Staging area

Лично я думаю, что студентов гораздо больше смущает область gitindex / cache / staging, чем hgанонимные головы. Я предпочитаю hgделать эту расширенную функциональность необязательной в командной строке, так как gitпредполагается, что вы всегда хотите / должны ее использовать.

Я также думаю, что область подготовки поощряет коммиты, которые не были протестированы или даже скомпилированы. Так как во многих местах, где я работал, имелась функция «не фиксировать», если она не компилирует правило, я предпочел бы отложить / спрятать изменения, которые мне сейчас не нужны, перезапустить модульные тесты и зафиксировать версию, которая Я знаю, компилирует.

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