Системы контроля версий являются неотъемлемой частью любого проекта по разработке программного обеспечения. Отслеживая изменения в исходном коде, он обеспечивает более полезную отладку, лучшую разработку функций и более эффективный рабочий процесс для команд. Современный взгляд на VCS — это распределенная модель, основными вариантами которой являются Git и Mercurial.
С абсолютным доминированием GitHub на рынке (настолько, что многие начинающие программисты не понимают, что Git и GitHub — это не одно и то же — GitHub — это платформа, использующая Git), индустрия решительно пошла в направлении Git. а не Меркуриал.
Это печально, потому что я твердо верю, что Mercurial лучше, чем Git.
Я должен добавить здесь оговорку, что Git все еще намного лучше, чем CVS или Subversion или любая другая система VCS старой школы. Если вы все еще используете CVS или Subversion, пожалуйста, ради всего хорошего, ОСТАНОВИТЕСЬ!
Хорошо, в сторону. Причина, по которой я предпочитаю Mercurial, на самом деле не в Mercurial (хотя я предпочитаю ветвление Mercurial, чем в Git), а в TortoiseHG. Эта программа содержит предварительно упакованный набор всего, что вам нужно для эффективного рабочего процесса — она включает в себя Mercurial, WinMerge (одна из лучших утилит для сравнения), KDiff3 (лучший инструмент для слияния) и необходимые инструменты для синхронизации с удаленными репозиториями. И самое главное, инструментальные средства TortoiseHG — безусловно, лучший графический интерфейс для любой системы контроля версий.
Я слышу, как фанаты Git/Linux/Линуса Торвальдса вопят: «НАСТОЯЩИМ программистам не нужен графический интерфейс!», «Все, что вы можете делать в графическом интерфейсе, вы можете делать из командной строки!» и т. д. Просто остановитесь. В правильном контексте графический интерфейс — это самый мощный способ взаимодействия с программой. И это один из таких контекстов. Позволь мне объяснить.
Разница между Mercurial/Git и более старыми системами VCS заключается в концепции наборов изменений — каждая фиксация представляет собой набор изменений в коде. Это означает, что историю репозитория можно рассматривать как ориентированный граф. Пока это верно как для Mercurial, так и для Git. Но что делает TortoiseHG, так это делает этот граф центральным элементом рабочего процесса — слияние, сравнение, ветвление и т. д. — все это легко интегрируется в граф. Хотите сравнить всю кодовую базу от 6 месяцев назад до текущей главы? Вы можете сделать это в два клика. Попробуйте сделать это в командной строке — это займет как минимум пару минут, если у вас уже настроен инструмент сравнения каталогов. Когда вы пытаетесь разделить ошибку пополам, это время складывается.
На метафизическом уровне репозиторий — это история развития кодовой базы. Вот что показывает нам график. Сделать граф центральной частью нашего взаимодействия с репозиторием имеет смысл, потому что он ближе всего к его «истинной природе».
Существует множество графических интерфейсов Git (например, Sourcetree и GitKraken). Но все они, похоже, низводят представление графа до гражданина второго сорта. Графический интерфейс, поставляемый с Git, даже не имеет графика в главном окне. И ни один из них не поддерживает ту базовую концепцию, о которой я упоминал ранее, — изменение кодовой базы в два произвольных момента времени. SourceTree, по крайней мере, позволит вам определить пользовательские команды, чтобы вы могли вместе взломать ярлык каталога diff — но это не обязательно! Это одна из тех вещей, которые должны просто работать. Смысл VCS в том, чтобы облегчить другую работу — в тот момент, когда начинает казаться, что реальная работа — это проблема. Mercurial+TortoiseHG просто работает.
И это ключ. Mercurial+TortoiseHG просто работает. Git ... просто делает вещи слишком сложными. Фанаты Git попытаются выдать это за особенность: «Если вам не нравится Git, это потому, что вы не эксперт. НАСТОЯЩИЕ программисты могут заставить его делать все, что им нужно». Но это неправильная точка зрения. Программировать сложно; ВКС быть не должно.
