О Git-ах, Hub-ах и Open Source Как работают ключевые структуры разработки открытого ПО
Линуса Торвальдса, создателя Linux, безусловно есть за что уважать. Этот человек изменил само представление о программировании, заложив основы Open Source на десятилетия вперед. И дело не только в разрушении монополии IT-корпораций на создание ключевого софта, дело в революции софтостроения. И знаменем этой революции стал Git.
Что такое Git и СКВ
Разработка ядра Linux шла с 1991 года в режиме коллективного творчества. Можно себе представить, как сложно синхронизировать изменения, вносимые в код, когда этим занимается не нанятая команда, сидящая в одном офисе и контролируемая работодателем, а множество программистов со всего мира. С 1991 по 2002 годы изменения передавались между разработчиками в виде патчей и архивов. В 2002 году проект ядра Linux начал использовать проприетарную децентрализованную СКВ BitKeeper, а после того, как ее бесплатное использование стало невозможным (это случилось в 2005-м), Линус Торвальдс разработал свою собственную утилиту – Git, которая изменила мир едва ли не больше, чем сам Linux.
Git – это одна из систем контроля версий (СКВ). То есть система, фиксирующая изменения в проекте в течение времени и позволяющая вернуться к определенному моменту работы. Даже если вы далеки от программирования, то наверняка пользовались элементарной системой СКВ, вызываемой сочетанием кнопок Ctrl (Command)+Z. Она встроена на всех десктоп-платформах и предоставляет возможность отменять действия, совершенные пользователем над файлом и возвращаться к его предыдущей версии.
Системы СКВ делятся на три больших группы.
Локальная СКВ
Простейший подход – сохранять проект на разных этапах в разные файлы, копировать их из каталога в каталог. Нужно откатить изменения? Берите более старый файл и работайте дальше ним. Примитивно и очень неудобно – особенно, если над проектом работает более одного человека. Более продвинутый метод – добавить к этому простую базу данных, которая хранит записи обо всех изменениях в файлах, осуществляя «контроль ревизий». Одна из популярных СКВ такого типа – система RCS. Она хранит на диске наборы патчей (различий между файлами) в специальном формате и может воссоздавать состояние каждого файла в заданный момент времени.
Централизованная СКВ (ЦСКВ)
Практически то же самое, но на сервере с общим доступом, который позволяет работать над проектом совместно. Довольно распространенный подход, особенно в больших IT-компаниях. Такие системы, как CVS, Subversion и Perforce, являются клиент-серверными. ЦСКВ являлось стандартом на протяжении многих лет, у него есть свои достоинства: все разработчики проекта в курсе, чем занимаются коллеги, а администраторы имеют полный контроль. Ну и вообще – гораздо проще администрировать ЦСКВ, чем локальные базы на каждом клиенте.
Однако сейчас от ЦСКВ часто отказываются даже внутри компаний из-за врожденного недостатка: при проблемах с сервером доступ к проекту пропадает у всех, никто не может сохранить изменения, работа останавливается. Единая точка отказа – это риск потерять одним разом все. Кроме того, ЦСКВ не допускают ветвление и слияние, параллельная разработка в такой модели невозможна.
Распределенная СКВ (РСКВ)
Git относится к распределенным СКВ. Они отличаются тем, что каждый пользователь держит у себя полную копию репозитория вместе с историей. Клиенты не просто скачивают снимок всех файлов (состояние файлов на определенный момент времени) – они полностью копируют все. Если любой из серверов обмена данными исчезнет, клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных. Кроме того, РСКВ могут параллельно взаимодействовать с несколькими репозиториями и рабочими группами, применяя разные подходы в рамках одного проекта, что невозможно в централизованных системах.
РСКВ – это не только Git. Распределенными являются такие СКВ, как как Mercurial, Bazaar, Darcs. Но Git отличается тем, что хранит информацию не в виде списка изменений в файлах, а в виде набора снимков. Таким образом он поощряет процесс работы, при котором ветвление и слияние являются нормой, и меняет подход к групповой разработке ПО. Благодаря этому стало возможно само явление Open Source.
Git и Open Source
Git – это в первую очередь инструмент совместного создания кода. Каждый участник проекта работает со своей копией репозитория: дописывает, исправляет, создает новые функции и версии. Это называется «форкинг репозитория». Программист создает новый проект на основе существующего – делает «разветвление». Скопировав существующий репозиторий, вносит в него изменения, сохраняет новую версию в качестве нового репозитория, и это становится его собственным проектом. Поскольку это новый проект, центральное хранилище не будет затронуто. Но если «главный» репозиторий обновлен, это обновление можно применить и к любому его форку.
Система контроля версий позволяет всем участникам команды свободно перемещаться между ветками других разработчиков для копирования нужных фрагментов кода и не ждать обновления основной ветки для продолжения работы. Если потребуется, то изменения, внесенные в форках, могут быть внесены в мастер-ветку потом – при одобрении администратора проекта и при отсутствии конфликтов версий. Так основной проект быстро развивается, а все его участники не мешают друг другу и друг друга не ждут.
Но что еще важнее, на одном дереве мастер-проекта могут расти самые разные самостоятельные ветви, которые становятся отдельными программными продуктами. Это составляет главное преимущество Open Source – никто не пишет весь код с нуля.
Приблизительная аналогия – если вы хотите создать велосипед с мотором, вам больше не нужно изобретать собственный велосипед и собственный мотор. Вы можете найти среди мастер-веток велосипед с достаточно крепкой рамой и сделать его форк. В рамках собственной ветки вы доработаете раму креплениями под мотор, уберете педали, если они больше не нужны, добавите на руль управление газом и так далее. На основную ветку «велосипед с крепкой рамой» это никак не повлияет, а вы сэкономите кучу времени. Более того – дальше вы можете найти проекты компактных моторов, выбрать среди них тот, который устраивает вас по характеристикам, сделать его форк и слить со своим проектом. После этого вы можете подогнать этот мотор под ваши крепления на раме. Причем если в основной ветке мотора его потом улучшат – эти изменения можно применить и к вашему проекту.
Чтобы реализовать всю эту систему, нужно место, где есть выбор как велосипедов, так и моторов. Для Open Source таким местом стал GitHub.
Git и его Hub
GitHub – это веб-сервис, на котором размещены миллиарды строк (более 10 TB) кода. Он используется для хостинга и совместной разработки IT-проектов сообществом более шести миллионов человек и основан на системе контроля версий Git. И одновременно, это социальная сеть для разработчиков. GitHub позволяет пользователям общаться с единомышленниками, следить за работой других людей и так далее.
Почему GitHub? Потому что им пользуются все. Есть аналогичные по функционалу платформы, такие как BitBucket или GitLab, но, если вы ищете какую-то библиотеку, вы в 99% случаев найдете ее на GitHub. Просто потому, что там больше людей, больше проектов, больше всего.
GitHub используют не только программисты. Там есть проекты из других отраслей: медицина, образование, ритейл и многое другое. Например, там есть репозиторий, хранящий интерактивную историю об изменении географии всех избирательных округов США. Система контроля версий нужна многим проектам – например, команде сценаристов сериала или писателю и его редактору.
И тем не менее – Git и GitHub не одно и то же. Первый – программное явление, второй – социальное, со всеми присущими таковым минусами. Например, несмотря на декларируемую и поддерживаемую большинством пользователей идеологию Open Source, принадлежит он самой проприетарной на свете компании Microsoft. Это периодически приводит к тому, что площадка модерирует контент и манипулирует доступом.
Так, например, GitHub удалил страницы, содержащие код программы DeepNude – приложения на основе искусственного интеллекта, которое «раздевает» женщин на фотографиях. Решение этически понятное, но все же не в духе Open Source.
Крупная химико-фармацевтическая корпорация Abbott Labs добилась удаления с GitHub бесплатной программы, которая позволила бы людям с диабетом использовать данные об уровне сахара в крови. В компании заявили, что это наносит им коммерческий ущерб.
GitHub по просьбе испанской полиции удалил приложение протестующих в Каталонии.
Кроме того, ветвящаяся структура Git имеет врожденную уязвимость – если недобросовестный разработчик-администратор добавит вредоносный код в мастер-ветку, то он окажется во всех форках. Так, недавно автор пакета node-ipc (предназначен для межпроцессного взаимодействия, используется в vue-cli, Unity, больше миллиона загрузок за неделю) внес в него код, который удаляет все файлы с устройства, если этот код был запущен с российского или белорусского IP.
***
Распределенная система контроля версий Git очень много сделала для принципа «Social Coding», на котором строится система Open Source. Благодаря ей пользователи не стали заложниками глобальных IT-корпораций, получив альтернативы проприетарным программным продуктам.
Будем надеяться, что тренд на разрыв глобальных связей всемирного IT-сообщества не скажется на идеологии Open Source, и она будет развиваться и впредь.
Использованные источники: