Почему Git такой сложный
16 ноября 2022 г.Когда вы учитесь программировать, люди часто рекомендуют изучить Git. В теории это звучит просто: программа для отслеживания изменений в вашем коде, которая поможет вам восстановить предыдущие версии кода, когда они вам понадобятся. Кроме того, это инструмент, который используется практически везде в отрасли. На практике… Git может, мягко говоря, сбивать с толку.
Почему так должно быть?
Интерфейс командной строки — CLI
Большинство обычных пользователей компьютеров не привыкли к роскоши текстовых интерфейсов. Я называю это роскошью, потому что, как я писал ранее, есть несколько больших преимуществ. к этому, хотя может потребоваться некоторое время, чтобы привыкнуть к пользовательскому интерфейсу. Итак, если ваши ассоциации совпадают с ассоциациями в списке:
кошка— пушистое животное,cd— как люди слушали музыку иgrep— звукоподражания,
тогда, скорее всего, ваш первый опыт работы с Git будет сопряжен с дополнительными трудностями при изучении основ командной строки. Что-то, что Windows 95 и ему подобные забрали у вас.
Цели разработки Git
Git никогда не был простым. Он создавался с разными целями: и более важными, и более сложными.
Надежное хранение сохраненных данных
Git предназначен для того, чтобы всегда возвращать вам данные точно в том виде, в каком они были сохранены, ИЛИ сообщать вам, что репозиторий поврежден. И он отлично справляется с этим — вы можете быть уверены, что состояние, которое вы получаете при проверке коммита, точно такое, каким его задумал автор. Конечно, это предполагает, что они знали, что делают.
Как Git обеспечивает такую надежную защиту данных? Он делает это умным способом: сохраняет все — коммиты, папки и файлы. Каждый объект идентифицируется криптографическим хешем его содержимого — числом, генерируемым на основе содержимого объекта, которое изменится, если что-либо изменится внутри файлов. Поскольку ссылки между объектами также хешируются, почти невозможно вмешаться в репозиторий, чтобы Git не заметил, что что-то не так. И даже в этих случаях осмысленный код будет заменен длинной текстовой тарабарщиной.
Работа в незащищенных сетях с недоверенными участниками
Поскольку все идентифицируется с помощью криптографических хэшей, Git не нужно доверять большей части сети, чтобы сохранить данные в целости. Git защищен от атак «человек посередине»: никто не может внедрить значимый код между двумя узлами Git. Конечно, если кто-то может прочитать коммиты, для которых он не предназначен, это тоже проблема, но с менее опасными последствиями, чем у злоумышленников, внедряющих код в кодовую базу.
Для дополнительного уровня безопасности Git предлагает регистрацию коммитов — дополнительный способ убедиться, что коммит создан человеком, который назначен его автором.
Поддержание обратной совместимости
Интерфейс Git сложнее, чем должен быть, потому что он уважает старые привычки своих пользователей. Я изучил Git в 2011 году и до прошлой недели не замечал новой команды git switch, которая рекомендуется для смены веток. То, как я это делал (git checkout + различные флаги), по-прежнему работает нормально. Git отдает предпочтение старшим пользователям и их привычкам, а не простоте для новых пользователей, что подводит нас к следующему пункту.
Удобство для суперпользователей
Git – это инструмент, созданный специально для суперпользователей. Он был написан Линусом Торвальдсом для управления кодовой базой Linux — задача не для новичков. Основные пользователи Git разрабатывают операционные системы, имеют многолетний опыт программирования и живут внутри командной строки. Все другие варианты использования случайны и не являются главной заботой людей, разрабатывающих Git.
Компромиссы простоты
При разработке систем ничто не бывает бесплатным, включая простоту для пользователей.
Скрытие сложности
Когда вы имеете дело с проблемой, которая по своей сути сложна, вы упрощаете решение, абстрагируя сложность. Это прошло? Нет, это просто скрыто от пользователя. Например, в случае с интернет-соединением я и большинство людей понимаю качество соединения только как количество полосок на 📶:
- меньше — плохо
- чем больше, тем лучше
Этого достаточно для использования Интернета, но это затрудняет понимание и устранение любых проблем с подключением.
Git сосредоточен на раскрытии всех сложностей, связанных с параллельным изменением файлов и асинхронной синхронизацией. На противоположном конце у вас есть прямой доступ к общему диску. Он прост в использовании, но что произойдет, если два человека попытаются отредактировать один и тот же файл одновременно? Одному повезет, и он сохранит свои изменения, а другой все потеряет. Не самый лучший рабочий процесс, особенно если потерянные изменения стоят часов дорогостоящего труда. Поскольку Git показывает пользователю все проблемы, которые могут возникнуть в этой ситуации, он позволяет разумно разрешать конфликты в файлах, что в некоторых случаях требует, чтобы пользователи делали это вручную.
Простой и безопасный
Еще одна часть Git, которая сбивает пользователей с толку, — это очень длинные идентификаторы коммитов, а также невозможность запомнить числа. Даже в удобной для пользователя сокращенной форме они выглядят как 0828ae1. И полный идентификатор: 0828ae10b20500fbc777cc40aa88feefd123ea5e. Можем ли мы вместо этого использовать только номера по порядку или использовать только имена ветвей? Проблема в том, что идентификаторы коммитов — это хэши, которые гарантируют целостность данных — они гарантируют, что коммит X на моей машине совпадает с коммитом X на удаленной или вашей машине. А несовпадения между ними могут появляться по разным причинам:
- преднамеренные — перебазирование, исправление, сжатие или любые другие операции, изменяющие историю.
- непреднамеренный — ошибка или атака на кодовую базу
Упрощение интерфейса и скрытие формы идентификатора фиксации лишило бы пользователя возможности понять, что происходит с кодовой базой, которую он запускает на своем компьютере. А поскольку код по определению запускается на компьютере, любая уязвимость безопасности будет чрезвычайно опасной.
Правильный ли это подход?
Когда я изучал Git, это было еще в новинку: я изучал его в 2011 году, а Git был создан в 2005 году (первая фиксация взята из Чт, 7 апреля 15:13:13 2005 -07:00). В то время я использовал SVN на работе и Mercurial часто рассматривался как более удобная альтернатива Git. Вы слышали эти имена в последнее время? Git почти полностью доминировал на рынке контроля версий. Он приобрел большую популярность с появлением GitHub, но даже если это сложно для новичков, это очень эффективный инструмент, и он никуда не денется.
Что делать начинающему программисту?
Мой совет: выучите его как можно раньше. Маловероятно, что Git скоро станет проще. Или когда-либо. Системы контроля версий в целом избавляют от головной боли при программировании. Я не могу представить себе эффективную работу с кодом, если вы изо всех сил пытаетесь перемещать версии своей кодовой базы. Хорошее изучение Git поможет вам сосредоточиться на проблемах с кодом, а не бороться с потерянными файлами или исправлять так называемые «проблемы с Git», которые почти всегда связаны с тем, что люди сами портят свой репозиторий.
Кроме того, изучение Git стало обрядом посвящения для новых разработчиков. Как разработчик, вы должны использовать его, и Git сделает вашу жизнь невыносимой, если вы попытаетесь использовать его, не разбираясь в нем. Разумный выбор — изучить его на своих условиях, а не ждать, пока отзывы рецензентов или проблемы с кодом заставят вас изучить его, одновременно выполняя другие обязанности.
Как узнать больше?
Если вы хотите узнать больше о Git, зарегистрируйтесь здесь, чтобы получать новости о моих новостях, посвященных Git. содержание.
:::информация Также опубликовано здесь.
:::
Оригинал