Справочник по Git и GitHub · модуль 1 · что такое контроль версий
Глава 1.1
Откуда
взялся Git
Git написал Линус Торвальдс в апреле 2005 года, когда ядро Linux осталось без системы контроля версий. В главе разобрано, какую задачу он решал, какие системы были до Git и как эта задача определила его устройство.
- Категория
- История и основные понятия
- Уровень
- Начальный
- Связанные темы
- Git и GitHub, устройство истории
- Зачем это знать
- Понимать, какую задачу решает Git и чем объясняется его устройство
§1Версии файла без Git
Без системы контроля версий прошлые варианты сохраняют копиями: перед каждой крупной правкой файл копируют под новым именем. Через две недели работы над курсовой папка выглядит так:
По таким копиям нельзя быстро узнать, чем курсовая_испр_2 отличается от курсовая_испр, кто и когда добавил третью главу и в каком файле осталось введение до правки недельной давности. Чтобы это выяснить, файлы открывают рядом и сравнивают вручную.
Со вторым участником работы становится больше. Он тоже делает копии под своими именами и присылает файл курсовая_финал_Ивана.docx. Соединить его с файлом курсовая_финал_точно_последняя.docx можно только вручную, абзац за абзацем. Чем больше проект, тем больше такой работы: в ядре Linux миллионы строк кода и тысячи участников.
Имя файла не хранит сведений о том, какие строки изменились и зачем. Эти сведения записывает программа контроля версий.
§2Что делает система контроля версий
Система контроля версий — это программа, которая хранит последовательность изменений проекта. Папка проекта остаётся одна, все прошлые состояния записаны в служебной истории, и к любому из них можно вернуться.
Дальше в каждой главе используются три термина. Каждый показан на репозитории этого справочника.
Репозиторийпапка проекта вместе с историей
Файлы проекта лежат в папке как обычно, их видно в списке. История хранится рядом, в скрытой папке .git. Когда репозиторий выложен на GitHub, тот же список файлов виден на странице проекта.
index.html, styles.css и папка temy, что лежат на диске автора. Строка 8 Commits считает сохранённые состояния, 1 Branch — линии разработки.Коммитодно сохранённое состояние проекта
В коммит входит содержимое файлов на этот момент, имя автора, дата и пояснение, что сделано. Открыв коммит, видно построчно: красным — что убрали, зелёным — что добавили.
ea99758 этой книги. Сверху — пояснение автора, ниже 3 files changed и +61 −61: столько строк добавлено и убрано. Красная строка — как было, зелёная — как стало.Историяцепочка коммитов от первого до последнего
Коммиты выстроены по времени, у каждого свой автор, дата и короткое имя из семи символов. По этому списку видно, как проект пришёл в сегодняшнее состояние и какой коммит что принёс.
Ассоциация: сохранения в игре
В игре вы сами решаете, когда сохраниться, и подписываете сохранение: «перед боссом», «нашёл ключ». Список сохранений показывает пройденный путь, и с любого можно начать заново.
Коммит — то же сохранение: момент выбираете вы, пояснение пишете тоже вы. История — список сохранений, откат возвращает проект к выбранному состоянию.
Где не совпадаетИгра держит один слот и перезаписывает его. Git не стирает прошлые сохранения: каждое остаётся в истории, и к нему можно вернуться.
Зачем это нужно в работе
- Сломалось после обновления. Сайт работал утром и перестал вечером. По истории видно, какие изменения были между этими моментами, и можно вернуть рабочее состояние одной операцией, пока разбираетесь с причиной.
- Непонятная строка в чужом коде. Git показывает, в каком коммите она появилась, кто её написал и что человек тогда пояснил. По этим сведениям понятно, у кого спросить о причине.
- Двое правят один проект. Правки не нужно сводить вручную: Git соединяет их сам и останавливается только там, где два человека изменили одну строку.
- Проверка чужой работы. Руководитель смотрит изменения последнего коммита: что убрали и что добавили. Такая проверка называется ревью.
В копиях папок нет автора, даты и пояснения, поэтому ни одна из этих задач копиями не решается.
Что меняется на практике:
Git — одна из таких систем, до него были другие. Они разобраны в следующем параграфе.
§3Как это решали до Git
Программы пишут коллективно с 1960-х годов, и первые системы контроля версий появились задолго до Git.
Марк Рокайнд пишет в Bell Labs систему SCCS для мейнфреймов IBM. Она хранит версии одного файла и показывает разницу между ними.
Вальтер Тихи выпускает RCS. Работает с отдельным файлом, история хранится рядом с ним. Проект целиком по-прежнему не отслеживается: есть версии файлов, а версии проекта нет.
CVS складывает историю на один сервер, куда ходят все разработчики. С CVS над проектом одновременно работают несколько человек. Отсюда пошла централизованная модель.
Subversion (SVN) исправляет недостатки CVS: переименование файлов, работу с каталогами, атомарные фиксации. Модель остаётся прежней — один центральный сервер, на котором лежит вся история.
Линус Торвальдс делает систему, в которой полная копия истории есть на каждом компьютере, а центральный сервер не обязателен.
Централизованно или распределённо
Git отличается от CVS и SVN местом, где хранится история проекта. Ниже две схемы.
Как было: один сервер в центре
История целиком лежит на сервере. На компьютере разработчика — только текущее состояние файлов.
- Когда сервер недоступен, нельзя сохранить версию и посмотреть прошлую.
- Каждое действие идёт по сети, поэтому история листается медленно.
- Если сервер потерян вместе с диском, потеряна вся история проекта.
Как стало: копия истории у каждого
У каждого участника полная история проекта на своём диске. Между собой они обмениваются изменениями.
- Без интернета работа продолжается: коммиты делаются локально.
- История открывается без обращения к сети: она лежит на вашем диске.
- Если сервер вышел из строя, проект восстанавливают из копии любого участника.
Ассоциация: один конспект на группу или у каждого свой
Вариант первый: конспект один, лежит у старосты. За каждой записью идут к старосте. Если староста заболел, группа остаётся без конспекта.
Вариант второй: конспект переписан каждым. Любой может заниматься сам, а новые записи участники передают друг другу.
Первый вариант — CVS и Subversion: история на сервере, без него работа стоит.
Второй — Git: полная история у каждого на диске, обмен по мере надобности. Сервер служит местом обмена, история хранится и без него.
Где не совпадаетПереписанные от руки конспекты расходятся: у каждого свои сокращения. Копии репозитория сходятся точно — одинаковое содержимое даёт одинаковые имена коммитов, и Git видит, где копии разошлись, а где совпадают.
В распределённой модели GitHub — ещё одна копия репозитория, с которой участники договорились сверяться. Особого положения у неё нет: Git одинаково работает с любой копией.
§4Ядро Linux и BitKeeper
К началу 2000-х над ядром Linux работали тысячи человек по всему миру. Ни CVS, ни Subversion такой нагрузки не выдерживали: история огромная, правки идут потоком, а ветки в централизованной модели дороги. До 2002 года Линус Торвальдс принимал изменения почтой — люди присылали заплатки текстом, и он накладывал их вручную. Со временем заплаток стало больше, чем один человек успевал разобрать.
В 2002 году ядро перешло на BitKeeper — распределённую систему Ларри Маквоя. В ней было то, чего не хватало: у каждого своя копия истории, ветки дешёвые, слияния автоматические. BitKeeper — закрытая коммерческая программа. Разработчикам ядра её отдали бесплатно, но с условием не участвовать в создании конкурирующих систем.
Ларри Маквой
Основатель компании BitMover и автор BitKeeper — распределённой системы, в которой ядро Linux разрабатывалось с 2002 по 2005 год. После его решения отозвать бесплатную лицензию началась разработка Git.
Фото: Eugene Zelenko, CC BY-SA 4.0 · Wikimedia Commons
Линус Торвальдс
Создатель ядра Linux. Писал Git как инструмент для собственной работы: ему нужно было принимать заплатки в ядро.
Фото: Krd, CC BY-SA 4.0 · Wikimedia Commons
Сообщество свободного программного обеспечения три года спорило, допустимо ли разрабатывать свободное ядро в закрытом инструменте. Спор закончился в апреле 2005 года. Эндрю Триджелл, известный по проекту Samba, разобрался в сетевом протоколе BitKeeper и написал программу, которая выгружала историю без фирменного клиента. Маквой счёл это нарушением условий и отозвал бесплатную лицензию для разработчиков ядра.
Ядро Linux осталось без системы контроля версий. Подходящей по скорости и по модели работы замены не существовало.
§5Апрель 2005 года: первые версии Git
Торвальдс написал свою систему. Ниже ход работы по датам.
Торвальдс начинает писать систему с нуля. Задача: принимать заплатки в ядро быстрее, чем это делает BitKeeper.
В списке рассылки LKML появляется письмо о новом инструменте. Постоянного названия и документации у него ещё нет.
Через четыре дня после начала работы Git уже пригоден для того, чтобы вести в нём собственную разработку. С этого дня история Git лежит в самом Git.
Две линии разработки впервые объединены автоматически.
Первый выпуск ядра Linux, собранный и опубликованный уже с помощью Git.
Торвальдс передаёт развитие Git Джунио Хамано и возвращается к ядру. Сам он продолжает пользоваться Git в работе над ядром.
Версия 1.0 вышла меньше чем через девять месяцев после начала работы.
Git писался под конкретные условия: огромный проект, тысячи участников, отсутствие доверия между ними и отсутствие центрального сервера. Этими условиями объясняется устройство Git.
§6Откуда название Git
Название расшифровки не имеет. В британском английском git — это ругательство в адрес неприятного человека, примерно «болван». Торвальдс объяснял выбор так:
«Я эгоистичный мерзавец и называю все свои проекты в честь себя. Сначала „Linux“, теперь „git“.»
В самом первом коммите Git автор описал проект как «the stupid content tracker» — «тупой отслеживатель содержимого» — и перечислил, что может означать название, «в зависимости от настроения»: от «случайного сочетания трёх букв» до «глобального информационного трекера», когда всё работает. В основе Git лежит простой механизм хранения, привычные команды надстроены над ним.
По-русски прижилось «гит», с ударением на единственный слог. Вариант «джит» неверен: слово читается так, как пишется.
§7Четыре требования Торвальдса
Инструмент писался под ядро Linux, поэтому требования к нему были известны заранее. Они объясняют устройство Git.
история — на вашем диске
без запросов по сети
Просмотр истории и переключение веток занимают доли секунды.
полная копия у каждого
сервер — по договорённости
Тысячи людей работают без общего сервера, обмениваясь изменениями напрямую.
ветка = указатель на коммит
Ветку заводят под каждую правку, даже мелкую. В SVN создание ветки занимало время, в Git это одна операция.
каждый коммит подписан хешем
e83c516…
Подменить старый коммит незаметно нельзя: изменение содержимого меняет хеш, а вместе с ним и хеши всех следующих коммитов.
Четвёртое требование связано с тем, как заплатки попадают в ядро: они приходят от незнакомых людей через десятки посредников, и нужен способ проверить, что по дороге ничего не подменили. Хеш даёт такую проверку.
§8Кто развивает Git
Торвальдс вёл Git только первые месяцы. В июле 2005 года он передал сопровождение Джунио Хамано, который участвовал в разработке с первых недель и с тех пор отвечает за выпуск версий.
Джунио Хамано
Ведёт Git с июля 2005 года: принимает изменения от сообщества, собирает выпуски, отвечает за совместимость. Все выпуски начиная с версии 1.0 собраны им.
Фото: Junio Hamano, CC BY-SA 3.0 · Wikimedia Commons
Ядро Linux
Первый пользователь Git. Требования ядра — скорость, ветки и проверка целостности — определили устройство Git.
Tux: Larry Ewing, Simon Budig, Garrett LeSage · Wikimedia Commons
Git распространяется под лицензией GPL версии 2: его можно использовать, читать исходный код и изменять. Отозвать право пользоваться Git не может никто, включая автора, поэтому ситуация с BitKeeper не повторится.
§9Git сегодня
Сейчас Git используют далеко за пределами ядра Linux. По опросам разработчиков, им пользуются свыше девяти из десяти. Открытый код крупных проектов хранится в Git-репозиториях:
Ядро Linux
Android
Google
Microsoft
Netflix
NASA
Яндекс
VS CodeЛоготипы: Tux — Larry Ewing и другие; Android — Google, CC BY 3.0; Google, Microsoft, Netflix, NASA, Яндекс, VS Code — общественное достояние. Все файлы взяты с Wikimedia Commons и принадлежат своим правообладателям.
Для Git появились сервисы, где репозитории хранят и обсуждают. Их несколько, и Git работает с любым:
GitHub · 2008
GitLab · 2011
Bitbucket · 2008
SVN · используетсяЛоготипы: GitHub — MIT; GitLab — MIT; Bitbucket — Atlassian, общественное достояние; Subversion — RRZEicons, CC BY-SA 3.0. Источник — Wikimedia Commons.
Subversion пользуются до сих пор. В проектах из тяжёлых файлов — чертежей, видео, игровых ресурсов — централизованная модель удобнее, потому что копия всей истории на диске каждого участника там не помещается. Git выгоден, когда история состоит в основном из текста.
Дальше в книге используется GitHub: на нём размещено больше всего открытых проектов, и он поддерживается Visual Studio Code без дополнительных настроек.
§10Частые заблуждения
§11Проверьте себя
Какую задачу решает система контроля версий, с которой не справляются копии папок?
Она хранит историю изменений: кто, когда и зачем изменил каждую строку. По копиям папок этого не восстановить: имя файла не содержит автора и причины правки, а разницу ищут вручную.
Чем распределённая модель отличается от централизованной?
Местом, где лежит история. В централизованной (CVS, SVN) она одна и находится на сервере, без связи с ним работать нельзя. В распределённой (Git) полная копия истории есть у каждого участника, поэтому коммиты делаются локально, история открывается без сети, а сервер нужен только чтобы обмениваться изменениями.
Почему появился Git: что произошло в апреле 2005 года?
Ядро Linux с 2002 года разрабатывалось в закрытой системе BitKeeper, отданной сообществу бесплатно. После того как Эндрю Триджелл разобрал её сетевой протокол, компания отозвала бесплатную лицензию. Подходящей замены не существовало, и Торвальдс написал свою систему: 3 апреля — первый код, 7 апреля Git уже вёл собственную разработку.
Кто развивает Git сейчас?
Джунио Хамано. Торвальдс написал первую версию и в июле 2005 года передал ему сопровождение. Хамано ведёт проект до сих пор.
Почему в Git ветку создают быстрее, чем в SVN?
В Git ветка — это указатель на коммит, а вся история лежит у вас на диске: создание ветки не копирует файлы и не требует сети. В централизованной модели ветка создавалась на сервере и стоила времени, поэтому её заводили редко и под крупные задачи.
Объясните своими словами, почему Git можно пользоваться без интернета, а SVN — нельзя.
В Git у вас на диске полная копия репозитория: можно смотреть историю, создавать ветки, делать коммиты — всё это локальные операции. Сеть понадобится только в конце, чтобы отправить накопленные коммиты на общий сервер. В SVN каждая фиксация идёт на сервер сразу, поэтому без связи версию сохранить нельзя.
§12Шпаргалка по главе
Git — система контроля версий
хранит историю проекта
репозиторий — проект с историей
коммит — сохранённое состояние
история — цепочка коммитов
2002 — ядро на BitKeeper
апрель 2005 — Git написан
июль 2005 — Хамано ведёт проект
SVN: история на сервере
Git: история у каждого
Итог главы
Git появился потому, что ядру Linux срочно понадобилась замена BitKeeper, а готовой замены не было. Отсюда его устройство: полная копия истории у каждого участника, локальные операции без обращения к серверу, дешёвые ветки и хеш, по которому видна любая подмена. Понятия репозитория, коммита и истории дальше используются постоянно. Следующая глава — о разнице между Git и GitHub.
- Письмо Линуса Торвальдса в рассылке ядра Linux о первой версии Git, 6 апреля 2005 года — lore.kernel.org.
- Первый коммит Git и его файл
README— github.com/git/git. - История Git, переход ядра на BitKeeper и отзыв лицензии — статья «Git» в Википедии и раздел «A Short History of Git» в книге Pro Git.
- Доля Git среди систем контроля версий — ежегодный опрос разработчиков Stack Overflow Developer Survey.
- Все изображения — Wikimedia Commons, лицензии указаны под каждым.