Читая блоги разработчиков мне из раза в раз встречалось понятие доселе незнакомое — репозиторий. Простите мне мой слог, кажется я перечитал Достоевского.
Этот пост входит в серию постов, под тегом Кибер-крестьянство.
Что это за репозиторий? Зачем он нужен? Какую функцию выполняет? В чем его смысл?
Я решил разобраться с этим — посмотрел много ютуба и попробовал это все настроить самостоятельно на виртуальном сервере. Для закрепления поделюсь как я это все понял, вдруг кто-нибудь на просторах интернета захочет найти объяснение от простого человека без непонятных команд и чёрных экранов. А то когда я читал блоги разработчиков, то команд видел много, а понять что делает каждая команда и главное зачем мы ее пишем — было не просто.
Объяснение от простого человека.
Программисты (по современному — разработчики) занимаются тем, что пишут код. Код программы пишется в текстовый файл. Если мы на него посмотрим, то увидим там команды, которые будут разными, в зависимости от используемого языка программирования. Языков много: какие-то заточены для написания приложений, работающих через браузер, какие-то просто универсальные, какие-то заточены для работы с ИИ и так далее.
Код программы надо где-то хранить. Причем хранить надежно — так, чтобы с ним ничего ничего не случилось, даже если ноутбук разработчика сгорит. А еще желательно, чтобы можно было откатиться назад, на момент когда все работало, если в коде будет допущена ошибка. А уж если разработчиков, работающих над одним проектом больше одного, то необходим инструмент, который поможет им организовать работу с кодом, чтобы они друг другу не пересылали его без конца при внесении правок одним из них, чтобы поддерживать постоянную синхронизацию.
Чтобы решить все эти задачи, разработчики сказали:
— А давайте код у нас будет храниться на сервере, а мы будем его оттуда скачивать, работать с ним и загружать обратно. А чтобы всё это делать каждый раз не вручную, перекидывая файлы мышкой, мы придумаем специальную программу, которая будет нам с этим и многим другим сопутствующим помогать.
Так появилось две вещи, которые работают в связке:
- Репозиторий — место, где хранится код программы.
- Системы контроля версий кода — программы, которые позволяют удобно работать с репозиториями и отслеживать изменения в коде.
Репозиторий может быть организован локально на компьютере в отдельной папке, но еще надёжнее хранить его на каком-нибудь сервере. Всё таки серверы защищены постоянным электричеством и к ним просто так не допускают кого попало (для этого существуют дата-центры). По сути, репозиторий — это папка с разными версиями файла с кодом программы.
Хранение в репозитории организовано по-умному, чтобы не множить занимаемое место при каждом сохранении. Код хранится в виде слепков состояния кода в разные моменты времени, но конкретная реализация зависит от того, какая выбрана система контроля версий кода.
Репозиторий хорошо и эффективно хранит код - текстовые файлы, но не эффективно хранит версии бинарных файлов - картинок, видео, всего, что не текстовое. Они будут храниться, но размер репозитория в этом случае будет распухать сильнее и это повлияет на пересылаемые данные при сохранении и синхронизации с репозиторием.
Самое интересное это то, что код программы распределяется между машинами всех разработчиков, его хранение становится распределённым.
Если с основным сервером, где располагается общий репозиторий что-то случится, то репозиторий со всей историей изменений можно восстановить с одного из ноутбуков и наоборот, потому что они полностью сихронизированы друг с другом. Нет критичной зависимости от центрального репозитория. Но при этом они не постоянно онлайн на связи друг с другом. Синхронизация организована другими методами - с помощью команд загрузки кода и его скачивания из центрального репозитория, а затем сравнения содержимого копий.
Создание очередного слепка кода называется сделать коммит, закоммитить. При создании коммита система просит написать комментарий. Это делает отслеживание того, что было изменено, удобнее в будущем.
Когда код пишет не один программист, а несколько, то все еще интереснее. В этом случае связка (системы хранения версий и репозитория) помогает настроить работу с кодом для всей команды: каждый разработчик может работать только над своей частью кода на своём ноутбуке и не мешать остальным. В начале дня все разработчики обновляют у себя на ноутбуках состояние репозитория, скачивая обновления к себе, а в конце дня грузят в центральный репозиторий свои наработки в коде за день. При этом если два разработчика по какой-то причине вдруг отредактировали один и тот же кусок кода, то система контроля версий покажет предупреждение, что они собираются поменять часть кода, которая уже обновилась, а они этого не видели, и спросит какое изменение принять.
Когда разработчик хочет подправить код, то первым делом он скачивает себе репозиторий на компьютер вместе со всеми историческими слепками, существующими для текстового файла с кодом программы. Дальше разработчик работает с кодом программы без интернета в своём локально репозитории, который полностью синхронизирован с центральным. Когда какой-нибудь баг исправлен, или фича доделана, разработчик синхронизирует локальный репозиторий, хранящийся на его машине с центральным, чтобы изменения стали доступны всем.
Разработку можно распараллеливать на параллельные разработки одной и той же программы — одна часть команды пишет основной функционал, а другая часть команды разрабатывает улучшение какой-то отдельной части программы. Для этого есть функционал так называемых веток репозитория. Каждую ветку можно разрабатывать отдельно. Когда фича будет готова, то изменения можно соединить, смёрджить, чтобы в основной версии кода программы появились доработки, создававшиеся отдельно от основной ветки.
Если над программой работает еще больше людей, то системы контроля версий позволяют создавать дополнительные роли — людей, ответственных за осмотр кода, сданного каждым программистом. Эти люди дополнительно просматривают и утверждают изменения, отправленные разработчиками, перед тем как разрешить его к загрузке в основной репозиторий программы. Это помогает сохранять контроль над основным кодом программы.
Современные процессы разработки сделаны так, что при отправке кода в репозиторий на стороне репозитория срабатывает автоматизация, которая сразу из кода собирает финальное приложение и опубликовывает его для доступа пользователей — это называется CI/CD. Continuous Integration (CI) и Continuous Delivery (CD) — или по-русски непрерывная интеграция, непрерывная доставка и развёртывание.
Люди, которые занимаются автоматизацией, нужной для разработки, созданием виртуальных серверов, баз данных и прочей инфраструктуры, которая будет использоваться финальным продуктом, настройкой репозиториев и систем контроля версий, организацией автоматизированного тестирования программ — называются девопс-инженерами. Они занимаются обслуживанием процесса разработки. Они — связующее звено между системными администраторами, разработчиками и тестировщиками.
Возвращаясь к теме репозиториев. Идея таких распределенных и центральных хранилищ кода, которые можно организовать с помощью свободного и бесплатного программного обеспечения, очень пригодилась мне для синхронизации заметок в Obsidian между устройствами, но об этом в другой раз.