[Перевод] Двадцать лет — ничто
В прошлом выпуске журнала мы утверждали, что английский язык стал в индустрии настолько вездесущим, что мы больше задаемся вопросом, почему используем именно его. То же самое можно сказать и о Git. Сложно представить себе, что каких-то двадцать лет назад ландшафт систем управления исходным кодом был разнообразнее и выбрать из этих систем какую-то одну было гораздо сложнее. Собственно, Git тогда еще и среди вариантов не значился. Прежде чем рассуждать, к лучшему или к худшему установилась гегемония Git, давайте ненадолго вернемся в прошлое.
Источник
В одном из самых знаменитых танго в истории Карлос Гардель пропел хорошо известные строки:
Ощутить… что жизнь — глоток свежего воздуха,
что двадцать лет — ничто,
что лихорадочный взгляд,
бродящий в тенях,
находит тебя и называет по имени.
Двадцать лет назад
Второе издание Совершенного кода Стива Макконнелла было опубликовано в 2004 году. На 668 странице этого девятисотстраничного талмуда мы находим единственное упоминание темы управления исходным кодом на всю книгу, длиной примерно в три четверти страницы. Больше ничего. ChatGPT без труда обобщил бы сказанное в этих абзацах в одном предложении: «Применение ПО для контроля версий — это хорошо, оно дает несколько существенных преимуществ». Не бог весть какие новости. От GitOps нас тогда отделяло очень многое.
В том же году, почти за двадцать лет ровно до момента опубликования этой статьи, увидела свет Subversion 1.0. Что такое Subversion? Возможно, самая недолговечная из всех благонамеренных идей в истории программирования. Видите ли, Subversion (или svn) должна была стать лучшей версией CVS (нет, не аптекой, а системой одновременных версий). «Лучше, чем CVS» в те времена подразумевало транзакциональность (базы данных, как насчет?) и сколько-нибудь улучшенную поддержку ветвления. Тогда, ребятки, мы о большем и не мечтали.
Линус Торвальдс, впрочем, мечтал. В 2004 году между разработчиками ядра Linux усиливались разногласия по поводу использования BitKeeper, лицензионной распределенной системы контроля версий, которая использовалась для управления исходным кодом ядра. И как же тут быть простому программисту? Что ж, у Линуса была традиция создавать ПО, в котором все нуждались и за которое никто не хотел браться. Была у него и другая традиция: называть всё подряд в свою честь. Согласно преданиям, первая версия Git была написана за пару недель.
CVS
Слышали когда-нибудь о CVS? Это система управления исходным кодом, которую Джоэл Спольски в сентябре 2000 года описал как неплохую (курсив его) в первом пункте своего одноименного теста Джоэла, предназначенного для улучшения ПО.
Я пробовал платные пакеты для управления исходным кодом и пробовал CVS, которая распространяется бесплатно, и должен вам сказать: CVS неплоха.
Да, первый шаг к улучшению ПО — это (шок, сенсация!) использование программ для управления исходным кодом. В скобках замечу, что я начинал свою карьеру программиста в 1997 году, и нет, мы не использовали никаких систем управления исходным кодом, даже CVS. Да, вы угадали: мы просто сохраняли файлы VBScript локально и загружали их по FTP. Если одни изменения перекрывали другие, то очень жаль, живем один раз. Мне пришлось дожидаться 2002 года, что впервые воспользоваться программой для управления исходным кодом (для любопытных, это была Rational ClearCase).
А Джоэле Спольски слышали? Ну, он приложил руку к созданию Stack Overflow, которым, полагаю, в какой-то момент на протяжении карьеры пользовался каждый. 24 года назад Джоэл был одним из первых инфлюэнсеров в зарождающемся информационном поле разработки ПО. Типа как Келси Хайтауэр, только с более неоднозначными взглядами. Или как Стив Йегге, только с менее неоднозначными взглядами.
Раз уж речь зашла о Stack Overflow, то вот вам пример передовых методов управления версиями в 2008 году. Один из самых первых вопросов, заданных на этом сайте, датирующийся 8 сентября 2008 года, касался как раз-таки того, какую систему контроля версий выбрать разработчику, работающему в одиночку. Что интересно, этот вопрос был задан в тот самый момент, когда в реальном мире бушевал финансовый кризис 2008 года. Наша индустрия вне всяких сомнений живет в пузыре. Но я снова отвлекаюсь от темы.
Я пытаюсь подыскать систему управления исходным кодом для личного использования, и чем проще, тем лучше. Главное, что мне нужно — возможность читать и извлекать старые версии своего кода. Других разработчиков, кроме меня, нет.
Ответы на этот вопрос составляют пространный каталог, содержащий практически каждую систему управления версиями, известную человечеству на тот момент.
Одиссея контроля версий Windows
Но вернемся в 2000 год. За несколько дней до того, как Джоэль Спольски опубликовал свой тест, Марк Луковски выступил с докладом на тему «Windows: одиссея программирования» на Четвертом Симпозиуме USENIX по Системам Windows в Сиэтле, Вашингтоне. Мистер Луковски был членом первой команды Windows NT с 1988 года до середины 2000-х. На момент написания статьи презентация к докладу еще остается доступна в сети, и я всерьез рекомендую с ней ознакомиться.
Причина в том, что в эту одиссею помимо прочего входило — угадали — управление исходным кодом. Из 14-го слайда мы узнаем, что команда Windows NT 3.51 пользовалась «системой, разработанной внутри компании», которая к 2000 году была «на последнем издыхании»:
Поддерживать компьютер в синхронизированном состоянии было тяжким трудом (неделя на настройку, два часа в день на синхронизацию).
Ой. Не лучший вариант для онбродинга новичков. Теперь вы понимаете, почему манифест Agile, опубликованный в 2001 году, считается таким революционным. Благодаря Реймонду Чену, возможно самому влиятельному преподавателю истории Windows, нам известно название этой внутренней разработки:
На ранних этапах Microsoft использовала систему управления исходным кодом собственного производства; формально она называлась Source Library Manager, но обычно ее сокращали до SLM и произносили как «слайм» (slime, слизь). Это была простая система без поддержки ветвления.
Из 24-го слайда презентации Марка Луковски мы узнаем, что компания Microsoft приняла решение перенести Windows 2000 на что-то под названием Source Depot. Реймонд Чен подтверждает:
Вскоре после выпуска Windows 2000 исходный код Windows был перенесен в систему управления исходным кодом, известную как Source Depot, которая являлась санкционированным ответвлением Perforce.
Почему Perforce? Это объяснялось огромными размерами исходной кодовой базы Microsoft Windows:
Объяснение сейчас, вероятно, прозвучит не так убедительно, как раньше, но Perforce в среднем лучше себя показывал на крупных репозиториях, чем Subversion. Это стало одной из причин, по которым Microsoft приобрела лицензию на исходный код Perforce для создания Source Depot; NT — это нечто чудовищное, и немногие продукты, как бесплатные, так и платные, способны с ним справиться.
Марк Луковски изложил преимущества Source Depot в двух пунктах на 24-м слайде своей презентации:
Настройка нового компьютера: 3 часа против 1 недели
Стандартная синхронизация: 5 минут против 2 часов
Использует ли команда Microsoft Windows Source Depot и по сей день? Как выясняется, нет. В 2017 году в статье на Ars Technica сообщалось, что Microsoft перенесла все 300 Гб исходного кода на Git. Там прозвучала еще одна отличная фраза, описывающая одиссею Microsoft в поисках систем управления исходным кодом:
Давным-давно у компании было нечто под названием SourceSafe, пользоваться которым, по общему согласию, было с нравственной точки зрения равноценно тому, чтобы бросить свой драгоценный код в мусорное ведро и поджечь, из-за склонности системы наносить повреждения базе данных.
Могу подтвердить его слова. К крайнему своему сожалению, надо сказать.
Переход Microsoft на Git, однако, не прошел без сучка без задоринки, и это привело к созданию проекта Git Virtual File System (GVFS):
Но Git не рассчитан на репозитории весом в 300 Гб, состоящие из 3,5 миллионов файлов. Microsoft пришлось взяться за проект по кастомизации Git, чтобы дать ему способность работать с масштабами компании.
Эпоха Git
Страсть Microsoft к Git достигла своего пика в 2018 году, с поглощением GitHub, той платформы, которая, как некоторые считают, сделала Git мэйнстримом. За три года до этого, ощущая дух времени, компания выпустила Visual Studio Code со встроенной поддержкой Git.
GitHub представил миру концепт pull request-ов еще в феврале 2008 года, позже его переняли GitLab, Gitea (и ее недавнее ответвление Forgejo) и BitBucket и он стал хлебом насущным в инспекции кода на следующие 15 лет. Но вместе с тем GitHub создал еще и парадокс в мире Git: внезапно распределенная система управления исходным кодом стала… централизованной. Некоторые люди в шоке от такого поворота событий, и их можно понять.
Сейчас идет 2024 год, и Git окружает нас. Долгий путь эволюции, который привел к господству Git в 2010-х (и, как видно, в 2020-х тоже), можно представить в виде последовательности программ с открытым кодом, сменяющих друг друга: SCCS в 1970-х, RCS в 1980-х, CVS в 1990-х и Subversion в 2000-х. Чтобы обеспечить гладкую миграцию, Subversion импортировал репозитории CVS, а Git импортирует репозитории Subversion. Но самое-то главное: системы контроля версий перешли от строго локальных типа SCCS и RCS, к архитектуре вида «клиент-сервер» (CVS и Subversion), а затем к распределенным системам типа Git и прочих, самая примечательная из которых — Mercurial. Кстати насчет Mercurial, а вы знали, что разработчики Firefox недавно решили от нее отказаться и перейти на Git?
На сегодняшний день для нас стало привычным клонировать целый проект на свой компьютер, после чего можно спокойно отключиться от сети и продолжать писать код полностью офлайн. Двадцать лет назад эта простая парадигма была совершенно немыслимой. И, кстати сказать: в вашем локальном репозитории также сохраняется полная хроника всех изменений, которые когда-либо вносились в проект. Подобную возможность системы типа «клиент-сервер», разумеется, предоставить не могли (спойлер: полная хроника была у сервера, а у клиента — только, так сказать, HEAD).
Git (и его доступные возможности для ветвления) изменил ход работы программистов на годы вперед. В январе 2010 года Винсент Дриссен опубликовал основополагающую статью под названием «Успешная модель ветвления в Git» и представил миру спорный концепт git-flow. Почему спорный? Ну, потому что большая часть мнений в разработке относится к спорным. Сейчас существуют GitHub flow и Atlassian Gitflow и много других вариантов рабочего процесса с ветвлением.
Репозитории Git стали богатыми на события: каждая отправка, слияние или операция с тэгами затрагивает какой-то рабочий процесс. Возникла целая индустрия с такими называниями, как Argo CD, GitHub Actions, GitLab CI/CD pipelines и Gitea Runner, обеспечивающая новый уровень автоматизации и удобства. Влияние Git в этой сфере так сильно, что понятием GitOps теперь обозначается целый сегмент индустрии. Только для развертывания ветки не используйте, я вас предупредил.
Теперь перед нами встает простой вопрос: что будет после Git? На данный момент оспорить его огромную популярность, наверное, не представляется возможным. Я говорю «наверное», потому что в нашей индустрии нельзя предсказать будущее. Есть два любопытных претендента, достойных упоминания: Pijul, написанный на Rust (хотя десять лет назад проект начинался на OCaml), и Fossil, написанный создателями SQLite. Во втором случае команда SQLite предоставила список аргументов против использования Git:
Будем откровенны. Мало кто станет спорить с тем, что Git предоставляет не лучший пользовательский опыт. Многие особенности имплементации просвечивают сквозь интерфейс. Интерфейс настолько плох, что появился даже пародийный сайт, генерирующий поддельные man-страницы.
Пока мы дожидаемся альтернатив получше, давайте почитаем man-страницу 7 giteveryday и призовем на помощь git-дополнения: SourceTree, TortoiseGit, Fugitive, Codeberg и Magit. Похоже, что в ближайшие двадцать лет мы будем хранить ход в репозиториях Git, нравится нам это или нет.
Habrahabr.ru прочитано 5290 раз
