🎉🐙🐱 20 лет Git: все такой же необычный, все такой же великолепный

Легендарному Git стукнуло 20! Вспоминаем, как проект, который Линус Торвальдс называл «тупым менеджером контента», стал незаменимым инструментом для всех, кто хоть раз писал код или даже просто хранил файлы.

Двадцать лет назад (7 апреля 2005 г.) Линус Торвальдс сделал первый коммит в Git. За эти годы Git превратился из скромного персонального проекта в абсолютно доминирующую систему контроля версий во всем мире разработки.

Для меня это было захватывающее путешествие. Я начал использовать Git вскоре после его появления, стал соучредителем GitHub, написал популярную книгу о нем, разработал официальный сайт и запустил ежегодную конференцию — этот проект не только изменил мир разработки, но и мою жизнь.

Истоки: патчи и архивы

Git родился из разочарования сообщества разработчиков ядра Linux в существующих системах контроля версий. Сообщество традиционно использовало списки рассылки для совместной работы — масштабируемый, распределенный метод с криптографической защитой.

Рабочий процесс выглядел так:

1. Публикация архива с зафиксированным состоянием проекта.
2. Разработчики скачивали и распаковывали его.
3. Вносили изменения (новые функции или исправления).
4. Создавали патч через GNU diff.
5. Отправляли патч в список рассылки.
6. Обсуждали изменения.
7. Мейнтейнер либо применял патч, либо запрашивал правки.
8. Повторить 1-7.

По сути, эта схема уже была простейшей распределенной системой контроля версий: у каждого локальная копия, а «правом на слияние» обладал тот, кто мог выложить новый архив на сервер.

Но процесс оставался громоздким — сложно управлять патчами, отслеживать что и кем было изменено, поддерживать параллельные ветки разработки, разрешать конфликты.

Инструмент BitKeeper был создан специально для таких задач и нравился Линусу, но его лицензия не соответствовала духу сообщества.

Первый коммит Git: как все начиналось

Раз уж мы говорим о Git, давайте взглянем на его первый коммит. Что умел Git в момент своего рождения?

Это тупой (но чертовски быстрый) менеджер содержимого директорий. Он не делает многого, но эффективно отслеживает содержимое директорий.

Первый коммит содержал семь простых автономных инструментов. Это были не привычные нам команды вроде git commit, а низкоуровневые утилиты для работы с базой данных — например, write-tree и commit-tree (префикс git- появился лишь через несколько недель).

Некоторые из них превратились в «сантехнические» (низкоуровневые) команды, существующие до сих пор (git cat-file, git write-tree). Другие сильно изменились (например, оригинальный read-tree больше напоминал современный git ls-files). Но базовые концепции сохранились.

С самого начала Git умел:

1. Создавать «снимки» с помощью update-cache (по сути, формируя tarball) и write-tree для записи в базу данных.
2. Создавать коммиты с помощью команды commit-tree, который описывает изменения, внесенные в новый архив, и указывает на предыдущую версию архива, от которой он произошёл.
3. Читать данные с помощью cat-file, read-tree и show-diff.

Линус изначально планировал создать только низкоуровневую «сантехнику», поверх которой кто-то другой напишет пользовательский интерфейс («фарфор»). Он стремился создать эффективное хранилище истории архивов, а не полноценную систему контроля версий, предполагая, что кто-то другой разработает этот слой.

Как я познакомился с Git: от рекламных экранов до GitHub

Впервые я столкнулся с Git, когда работал с другом Ником Хенгевельдом в стартапе Reactrix. Интересно, что мы использовали Git не как систему контроля версий (как большинство сегодня), а как распределенную систему отслеживания контента — ближе к изначальной задумке Линуса.

Мы обслуживали сеть рекламных экранов с «тяжелыми» медиафайлами. Сотни устройств требовали уникальных наборов роликов, подключались через медленные сотовые каналы, а контент постоянно менялся. Нам нужно было эффективно указывать: «устройству А нужны ролики 1, 2, 3, устройству Б — ролики 2, 3 и 4», с возможностью инкрементальных обновлений.

Git стал для нас механизмом распространения контента. Скрипт анализировал расписание, создавал уникальные деревья с нужными роликами, коммитил их в ветку устройства, а ночью каждое устройство выполняло fetch и checkout.

Преимущества такого подхода:

1. Передавались только измененные файлы с дельта-компрессией.
2. Общие ресурсы хранились как единый блоб для разных контекстов.
3. Тысячи комбинаций файлов без дублирования контента.

Ник активно участвовал в раннем развитии Git (добавил SSL в http-fetch, возобновляемые передачи, HTTP-push). Его первый патч приняли через 6 месяцев после первого коммита Линуса.

Мои первоначальные трудности с пониманием Git и последующее озарение подтолкнули меня к созданию Git Community Book, руководства Git Internals, сайта git-scm.com и книги Pro Git — все это привело меня в GitHub.

Истоки современного Git

Почему «глупый трекер контента» стал самой популярной системой контроля версий? Изначально Git не проектировался с точки зрения удобства использования. Первые месяцы команды были крайне низкоуровневыми — даже знатоки «сантехнических» команд не узнали бы ранние rev-tree, mkdelta или tar-tree.

Git задумывался как низкоуровневая инфраструктура, над которой другие инструменты построят свои системы контроля версий. Высокоуровневые «фарфоровые» команды, которыми мы пользуемся сегодня, постепенно просачивались в систему годами, начинаясь как шелл-скрипты для решения конкретных задач.

В ранние дни существовало несколько пользовательских интерфейсов поверх низкоуровневых инструментов Линуса. Самым популярным был git-pasky, превратившийся в "Cogito" Петра Баудиша, выпущенный всего через несколько дней после самого Git.

Со временем граница между «фарфором» и «сантехникой» размывалась, поскольку инструменты в ядре Git стали конкурировать с внешними скриптами. К 2007 году Cogito был заброшен, и идея отдельного «фарфорового» слоя над Git была оставлена.

Просматривая коммиты и письма двадцатилетней давности, удивительно наблюдать за рождением инструментов, которыми многие из нас пользуются каждый день.

Первый git log

Первая версия git log была элементарной и называлась git-rev-list --pretty:

#!/bin/sh
git-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}

Многие современные команды Git начинались как короткие скрипты на Shell или Perl, вызывающие базовые низкоуровневые функции. Со временем большинство из них переписали на C для лучшей портируемости.

Вывод первого git log выглядел почти так же, как и сейчас.

$ git-log-script
commit d9f3be7e2e4c9b402bbe6ee6e2b39b2ee89132cf
Author: Junio C Hamano <gitster@pobox.com>
Date:   Fri Apr 5 12:34:56 2024 -0700

    Fix bug

Рождение git rebase

История команды rebase началась в июне 2005 года с обсуждения рабочих процессов между Джунио Хамано и Линусом Торвальдсом.

Джунио описал свой процесс работы, включавший:

1. Начинаю с HEAD-ветки Линуса.
2. Повторяю цикл разработки и коммитов.
3. Запускаю git format-patch (отсутствует в дереве Линуса) для генерации патчей.
4. Отправляю их и жду, чтобы увидеть, какие из них будут приняты.
5. Делаю pull из ветки Линуса.
6. Отбрасываю свой HEAD, делая HEAD Линуса своим HEAD, при этом сохраняя изменения, которые я внес с момента форка от него. Для этого я использую jit-rewind.
7. Просматриваю патчи, которые Линус отклонил, и применяю те, которые я все еще считаю хорошими, создавая один коммит на патч. Для этого я использую jit-patch и jit-commit -m.
8. Возвращаюсь к шагу 2.

Линус предложил создать функцию re-base, которая бы переносила локальные коммиты поверх новой удаленной версии. Так родилась концепция, ставшая одной из ключевых в Git.

Как Осьминог стал частью Git и породил Октокота

Первое упоминание слова "Octopus" в списке рассылки Git относилось к особому типу слияния с несколькими родителями. Со временем "octopus merge" стал официальной стратегией слияния в Git.

Том начал искать клипарты с изображением осьминога, и это изображение от Саймона Оксли оказалось самым милым из всех подходящих вариантов. Так родился "Octocat" (Октокот) — талисман GitHub, представляющий собой котоподобное существо с щупальцами осьминога.

Будущее Git

Забавно, что я до сих пор использую Git во многом так же, как он изначально задумывался. GitButler применяет Git не только для обычных коммитов при отслеживании изменений кода, но и использует базу данных git для отслеживания истории проекта. В конечном счете, Git по-прежнему остается чертовски хорошим «тупым трекером контента», как и задумывал Линус.

Итак, с днем рождения, Git. Ты все еще странный. Ты все еще прекрасен. Спасибо за все.