Предлагаю вашему вниманию перевод небольшой статьи из блога Armin Ronacher — автора Flask, Jinja2 и много чего еще. На этот раз он поделится своими мыслями о Git — распределенной системе управления версиями файлов.
Git для меня интересная тема. Впервые я попробовал использовать Git, когда там не было вообще никакой системы команд, а Cogito считался многообещающим проектом. Не могу сказать, что мне это понравилось, в то время я в основном пользовался SVN, и он полностью решал все мои задачи. Вскоре я познакомился с Mercurial, и это была любовь с первого взгляда, положившая начало долгому и позитивному опыту использования этой VCS (version control system), которая получила в моем лице преданного сторонника. Только в 2008 году я перешел на Git, и мне потребовалось несколько попыток, прежде чем я понял, что пора переносить на него мои репозитории.
Чудовищная система команд Git
Подозреваю, что разработчик, перешедший на Git с любой другой системы контроля версий, будет неприятно удивлен отсутствием целостности в его командах. Steve Losh даже не поленился обыграть это в своих «коанах Git».
Тем не менее, каждый раз, когда эта тема снова обсуждается, я чувствую легкую растерянность, потому что не могу вспомнить никаких проблем с командами Git в моей ежедневной работе. Безусловно, синтаксис «git remove» отличается от «git branch» и «git tag» — но я и использую их для разных задач, даже не задумываясь о неконсистентности. Единственная странная команда, которую я помню, это «git show»: ее синтаксис для показа содержимого объекта каждый раз вызывает недоумение.
А вот про Mercurial и Perforce я могу легко вспомнить частую борьбу при выполнении обычных, рутинных операций — чего не скажешь о Git. Почему система команд Git не вызывает у меня такой неприязни?
Изучение команд vs. изучения Идеи
Раздумывая над этим вопросом, я пришел к выводу, что причина такого легкого принятия синтаксиса Git состоит в принципах его изучения программистами. В случае с Mercurial и Perforce разработчик осваивает набор заклинаний командной строки для решения конкретных задач, и все, что находится «под капотом», при этом опускается.
А для Git все наоборот: с первых страниц введения читателя отсылают к описанию внутренностей этой VCS, где подробно изложено, что и как работает.
Такой метод обучения пошел еще с тех времен, когда у Git вообще не было системы команд. Ожидалось, что разработчик будет вручную редактировать файлы в директории «.git»! Я помню свои первые эксперименты с этой системой, когда даже не существовало команды commit: .git/HEAD, а только симлинком на текущую ветку, и документированным способом коммита было:
echo "Commit message" | git-commit-tree $(git-write-tree) > .git/HEAD
Лишь через некоторое время операция «commit» была выделена в команду, но даже тогда инструкция по ее использования была… вот такой.
Git изначально не разрабатывался как VCS: он создавался как некая идея, которую могут использовать другие программы для создания VCS. И это фундаментально отличает процесс разработки Git от того, как разрабатывались все остальные системы управления версиями.
Безусловно, за последние 10 лет Git сильно изменился, и некоторые идеи в его основе поменялись, но основная суть трансформировалась не сильно. И есть некая красота в том, чтобы создать репозиторий с помощью Git 2005 года, затем коммит с помощью той же версии, а после смотреть лог с помощью Git 2015 года.
Конечно, для того чтобы работать с Git, систему его команд выучить придется, но возможность узнать основные идеи, лежащие в основе этой VCS, того стоит.
Хорошее поведение по умолчанию
Система команд Git, надо признать, не лучшая из возможных, однако они снабжены хорошим поведением по умолчанию, которое с каждым годом только улучшается. Поведение Git «из коробки» адекватно, самые популярные приемы работы соответствуют настройкам команд, а когда это не так — можно рассчитывать на открытое обсуждение. Для большинства задач существует «одобренный» способ их выполнения с помощью Git, и этот способ, как правило, легко изучаем. Работа с ветками в Git не менялась с момента его создания, и знания, полученные 10 лет назад, актуальны до сих пор.
Хорошая архитектура
Я считаю, что Линус, когда создавал Git, придумал для него чертовски хорошую архитектуру, которая потребовала в дальнейшем минимального количества изменений. Как показало время, работа с коммитами и объектами была реализована верно, так же как и механизм работы с ветками. Даже Mercurial сдался и теперь предупреждает пользователя о том, что создание именованной ветки — не лучшая идея.
Изучив основные концепции, заложенные в основе Git, я могу спокойно пользоваться всей широтой его инструментария. Безусловно, иногда приходится залезть в Google, чтобы освежить в памяти какие-то редкие команды, но такая необходимость почти не возникает в каждодневной работе. Ни разу у меня не было случая, чтобы я сломал репозиторий и у меня не получилось бы все починить.
Система команд Git лишена целостности и простоты, зато у его архитектуры присутствуют оба этих качества, и за это я Git и ценю.
Git на моей стороне
Одна из причин, почему я прощаю Git его систему команд и местами неудобное поведение: он всегда играет на моей стороне. Много раз я ломал репозиторий чудовищным образом, делая неверные мерджи и стирая не те данные, но ни разу не было случая, чтобы данные были потеряны или VCS оставила бы меня один на один с руинами.
В случае проблем я иногда делаю копию моей директории «.git» и затем в ретроспективе изучаю, что я сделал не так. Ситуации, когда восстановление невозможно, крайне редки — и это один из вариантов, где Git полностью раскрывает свой потенциал. Я до сих помню свои ошибки с другими системами контроля версий, которые взрывали репозиторий и делали невозможным его восстановление без участия разработчиков этих VCS.
На моей памяти не было ни одного случая сломанного репозитория по причине неверного использования Git или же из-за его внутренней работы, тогда как с другими VCS у меня есть печальный опыт сломанных рабочих копий Subversion, разрушенных серверов, разломанных воркспейсов Perforce и репозиториев Mercurial, поврежденных моими руками.
Самое худшее, что случилось на моей памяти с Git, — некорректные разрешения для ряда файлов в репозитории Flask, возникшие из-за бага GitHub.
Заключение
Думаю, я не отказался бы, чтобы такого софта, как Git, было больше. Программного обеспечения, где внутренняя логика работы является важной частью его взаимодействия с пользователем, а пользовательский интерфейс не отделен от черного ящика реализации.
Контрпримером такого ПО может служить когнитивное разделение, возникающее между мной и последними решениями Apple в софтостроении. Больше нет окна «сохранить как», а диалог «сохранить» теперь часто показывает кнопку удаления, даже если ничего еще не было сохранено в файловую систему. Слишком часто я перезаписывал презентации в Keynote по причине того, что логика работы файловой системы и логика работы пользовательского интерфейса кардинально отличаются друг от друга. Меня сильно огорчает, когда фундаментально разные операции (discard еще не сохраненных данных и стирание файла, уже сохраненного в файловой системе) названы и выглядят одинаково.
От переводчика
С автором статьи и другими знатными питонистами можно будет пообщаться в эту пятницу, 20 марта, в Санкт-Петербурге в рамках конференции PiterPy, на которую мы их пригласили :) На мероприятии также выступит Сергей Матвеенко, ведущий разработчик компании Positive Technologies, которая поддерживает мероприятие в качестве генерального спонсора.
Перевод: Григорий Петров, Positive Technologies
Автор: ptsecurity
