Двадцать лет назад, 7 апреля 2005 года, Линус Торвальдс создал самый первый коммит в «информационном менеджере из ада» Git.
За эти двадцать лет Git превратился из простого маленького личного проекта в самую масштабную и популярную систему управления версиями.
Лично для меня это было захватывающее приключение в мире ПО, со своими взлётами и падениями.
Я начал пользоваться Git лишь спустя всего несколько месяцев после первого коммита, и применение его было достаточно необычным. А затем я стал сооснователем GitHub, написал самую, наверно, популярную книгу про Git, создал официальный веб-сайт проекта, организовал ежегодную конференцию разработчиков и так далее — этот проект изменил мир разработки ПО, но лично для меня он стал огромным изменением в судьбе.
Я подумал, что сегодня, когда проект Git входит в свой третий десяток лет, было бы интересно вспомнить самые первые дни Git и немного рассказать о том, почему этот проект кажется мне бесконечно восхитительным.
В видео выше мы с Кирилом пьём вино и собираем самый первый коммит Git, изучая его первые возможности.
Прежде чем мы перейдём к истории Git и моему участию в нём, я хотел бы рассказать о причинах существования Git и про мировоззрение, на основе которого он развивался изначально.
Git возник из разочарования сообщества разработчиков ядра Linux в управлении версиями и удобстве совместной работы.
Сообщество разработчиков ядра всегда использовало для совместной работы почтовые рассылки. На самом деле, это очень крутой способ взаимодействия — он с лёгкостью масштабируется, сильно распределён, рассчитан в первую очередь на локальную работу, обеспечивает возможность обсуждений патчей, может быть защищён криптографически и так далее.
Если вкратце, сотрудничество через рассылки происходит так:
Я бы с радостью написал целый пост о том, как устроена совместная работа через почтовые рассылки, а также о её замечательных аспектах, но это уже тема для другой статьи.
Однако в таком мире системы управления версиями попросту были бесполезны — они казались шагом назад в функциональности. Они имели неуклюжие механизмы контроля доступа, они не были распределёнными и работали невероятно медленно.
Сообщество в основном работало с патчами и tarball, а существовавшие системы управления версиями были для него недостаточно хороши.
Процесс работы с патчами и tarball был своего рода первой распределённой системой управления версиями — у каждого имелась локальная копия, изменения можно было вносить локально, доступ к «мерджу» имел любой, кто мог записать новый tarball на сервер.
Однако процесс всё равно оставался довольно неудобным — нужно было возиться с патчами, помнить, что было применено и кто внёс изменения, отслеживать несколько патчей, разрешать конфликты и заниматься перебазированием.
Инструмент Bitkeeper был разработан как раз для работы над ядром; он стал попыткой создания системы управления версиями, соответствующей этому процессу, и Линусу он нравился. Однако выбранная разработчиками инструмента схема лицензирования не понравилась сообществу, для которого он был создан.
Если вы хотите больше узнать о Bitkeeper, то посмотрите этот эпизод Bits and Booze, в котором мы настраиваем его и показываем, как он использовался.
Важно понимать, что именно это стало причиной создания Git. На самом деле, он должен был стать не совсем системой управления версиями, а более совершенным способом работы с патчами и tarball — создавать снэпшот множества файлов и показывать различия, которые можно обсудить.
По большей мере, так и разрабатывалась его структура данных (связанные списки деревьев файлов и адресуемое по содержимому хранилище блобов), и эта структура фундаментально никак не поменялась с первого коммита и по сей день.
Если уж мы коснулись этой темы, то как выглядел первый коммит? На что был способен Git с первого момента своего существования?
Что ж, это был дурацкий трекер контента. Линус с самого первого дня говорил так:
Первый коммит был набором из семи простых автономных инструментов. Это было не что-то вроде
Некоторые из них эволюционировали в plumbing-команды, которые мы используем и по сей день, например, в
По сути, в своём самом первом коммите Git мог:
С самых первых дней проекта Линус говорил, что хочет создать все эти plumbing-инструменты, чтобы они стали бэкендом для какого-нибудь скриптового UI («porcelain») поверх них.
Он хотел создать эффективный инструментарий для работы с базой данных истории tarball, а не настоящую систему управления версиями. Подразумевалось, что этот слой напишет кто-то другой.
Подробнее об этом чуть ниже. Ну а пока…
Лично меня познакомил с Git примерно в этот момент времени мой друг и коллега по неудавшемуся стартапу Reactrix Ник Хенгевельд.
Мы с Ником занимались отправкой всех ресурсов для этой интерактивной рекламы на компьютеры торговых центров и кинотеатров по всей стране.
Любопытно, что мы использовали Git примерно так, как и задумывал Линус: как распределённый трекер контента, а не как систему управления версиями.
По сути, мы работали в рекламной фирме, которая координировала дисплеи электронных табло с достаточно «тяжёлыми» по весу графическими ресурсами. Для каждого из сотен дисплеев существовала уникальная комбинация рекламных роликов; большинство из них имели медленные мобильные подключения для передачи данных, а рекламные ролики часто менялись. То есть нам нужен был способ эффективно сообщать «для машины А нам нужны ролики 1, 2 и 3 (v1). Для машины B нужны ролики 2, 3 (v2) и 4», а также инкрементно обновлять их в случае появления новых версий роликов.
Мы пользовались Git, но не для отслеживания изменений в исходном коде, а как механизм распространения контента. Был создан скрипт для изучения нового расписания, записи уникальных деревьев, содержавших только нужные для каждой машины ролики, выполнения коммита дерева в ветвь соответствующей машины. После этого машины каждую ночь выполняли скачивание и hard checkout.
Такое решение обладало рядом интересных преимуществ.
Ник был довольно активным контрибьютором в проект Git на его ранних этапах, чтобы тот хорошо работал в нашем сценарии использования (он добавил в http-fetch поддержку SSL, добавил возобновляемую и параллельную HTTP-передачу, создал первое решение push на основе HTTP). Его первый патч был отправлен в сентябре 2005 года, всего спустя полгода после первого коммита Линуса.
То, что он познакомил меня с Git, мои мучения с его освоением и в итоге возникшее понимание его удобства мотивировало меня больше о нём писать и упростить обучение другим людям.
Это заставило меня составить Git Community Book, Git Internals Peepcode PDF, создать веб-сайт git-scm.com и написать книгу Pro Git. Всё это в конечном итоге привело меня в GitHub.
Первая версия git-scm.com, выпущенная мной в 2008 году. Сверху нарисован «блоб», поедающий «деревья».
Так как же этот дурацкий трекер контента стал самой популярной системой управления версиями в мире?
В предыдущем посте я говорил о многих причинах того, почему Git и GitHub «победили», но, вероятно, стоит вкратце сказать и о том, почему сам Git в конечном итоге оказался таким, каким мы его знаем сегодня. И, возможно, по ходу дела изложить пару забавных историй о том, как в нём возникло то, что мы знаем и любим.
Как вы могли понять из иногда недружелюбной, загадочной или несогласованной природы команд Git, он не был системой, изначально тщательно проектировавшейся с учётом удобства пользования.
В течение многих месяцев все команды git оставались невероятно низкоуровневыми — даже если вы знаете существующие plumbing-команды, то можете и не узнать ни одной из команд, существовавших на июнь 2005 года (
Но если Линус и команда разработки раннего Git изначально не рассчитывали, что Git на самом деле станет инструментом для управления версиями, и просто хотели создать инфраструктуру, то откуда взялись porcelain-команды, которые нам известны сегодня?
Они как бы самостоятельно прокладывали себе путь в течение долгих лет, в основном в виде скриптов оболочки, написанных для удовлетворения какой-нибудь потребности.
На ранних этапах существовало множество пользовательских интерфейсов, которые при помощи скриптов превращали бэкенд-инструментарий Линуса в нечто более удобное. Самым первым и долгие годы самым популярным из них был
Читая объявления о ранних релизах, можно уже ощутить возникновение инструментария, в который превратится Git.
Несколько месяцев спустя попытки разделения на porcelain и plumbing начали терпеть неудачу: инструментарий git стал конкурировать с инструментарием в porcelan-скриптах.
В течение одного-двух последующих лет в код ядра Git продолжали проникать новые скрипты, и, наконец, стало очевидно, что оптимальнее тратить время разработчиков на работу над инструментами, распространяемыми вместе с Git, а не на то, чтобы сохранять в инструментарии это разделение на plumbing и porcelain.
В 2007 году Cogito был «выставлен на продажу», а идея о том, что какой-то porcelain будет основным способом использования Git, была более или менее забыта.
Изучая все эти коммиты и письма, написанные двадцать лет назад, интересно наблюдать за рождением инструментов, которыми многие из нас пользуются ежедневно.
Первая версия
На случай, если вы не слышали о
На самом деле, многие современные команды начинались с этого — скрипт оболочки или на Perl длиной в несколько строк, выполнявший команды базового plumbing. Позже ради портируемости почти всё было переписано на C как встроенные функции, но многие первые версии команд были написаны на этих скриптовых языках.
Первый «git log» показался бы нам достаточно знакомым.
Есть много разных «первых», поэтому я расскажу только о ещё одном, потому что мне он кажется интересным. Знаменитая команда «rebase» родилась из обсуждения процесса работы Линусом и Хунио в июне 2005 года.
Хунио рассказывал Линусу, каким был его рабочий процесс:
Линус ответил, что на самом деле разработчикам здесь требуется «перебазирование» работы:
Тогда Хунио отправил в ответ простой скрипт, использующий новую команду
Насколько могу судить, это первое упоминание термина «rebase» в управлении версиями. Любопытно видеть, как рождалась история.
Меня много раз спрашивали, откуда в GitHub взялся «Octocat»; ответ тоже можно найти в этих ранних архивах.
Первый раз слово «octopus» в списке рассылки Git встретилось мне, когда Хунио сказал Линусу, что его патчи применялись последовательно, а не «осьминожно» («octopus»).
Под этим подразумевалось создание merge commit с несколькими родителями, то есть другой способ мерджинга нескольких патчей. Со временем «octopus merge» стала одной из допустимых в Git стратерий мерджинга. (Забавный факт: когда-то в Git была стратегия мерджинга «stupid»).
На очень ранних этапах GitHub Том искал что-нибудь, что антропоморфически можно использовать, как тотем Git, и «Octopus» показался единственным подходящим термином из лексикона Git. Том поискал клипарт с «octopus», и рисунок Саймона Оксли показался ему самым милым. Так родился «octocat».
Двадцать лет спустя кто-то может задать вопрос о том, каким будет будущее этого внезапно получившего популярность проекта.
Забавно, что я по-прежнему в каком-то смысле использую Git для того же, для чего он и задумывался. GitButler использует Git не только для создания коммитов с целью отслеживания изменений в коде, но и применяет базу данных git для отслеживания истории проекта. В конечном итоге, это всё ещё чертовски хороший дурацкий трекер контента, как и задумывал Linus.
Так что с днём рождения Git. Ты по-прежнему странный и прекрасный. И спасибо за рыбу.
За эти двадцать лет Git превратился из простого маленького личного проекта в самую масштабную и популярную систему управления версиями.
Лично для меня это было захватывающее приключение в мире ПО, со своими взлётами и падениями.
Я начал пользоваться Git лишь спустя всего несколько месяцев после первого коммита, и применение его было достаточно необычным. А затем я стал сооснователем GitHub, написал самую, наверно, популярную книгу про Git, создал официальный веб-сайт проекта, организовал ежегодную конференцию разработчиков и так далее — этот проект изменил мир разработки ПО, но лично для меня он стал огромным изменением в судьбе.
Я подумал, что сегодня, когда проект Git входит в свой третий десяток лет, было бы интересно вспомнить самые первые дни Git и немного рассказать о том, почему этот проект кажется мне бесконечно восхитительным.
В видео выше мы с Кирилом пьём вино и собираем самый первый коммит Git, изучая его первые возможности.
Патчи и tarball
Прежде чем мы перейдём к истории Git и моему участию в нём, я хотел бы рассказать о причинах существования Git и про мировоззрение, на основе которого он развивался изначально.
Git возник из разочарования сообщества разработчиков ядра Linux в управлении версиями и удобстве совместной работы.
Сообщество разработчиков ядра всегда использовало для совместной работы почтовые рассылки. На самом деле, это очень крутой способ взаимодействия — он с лёгкостью масштабируется, сильно распределён, рассчитан в первую очередь на локальную работу, обеспечивает возможность обсуждений патчей, может быть защищён криптографически и так далее.
Если вкратце, сотрудничество через рассылки происходит так:
- публикуем tarball (что-то типа zip) известного состояния проекта,
- люди скачивают его и распаковывают локально
- вносят в него нужные им фичи или исправления,
- запускают для него GNU diff, чтобы создать патч, который мейнтейнер может применить к исходному известному состоянию, чтобы добавить фичу,
- отправляем по почте этот патч или несколько патчей в список рассылки,
- список обсуждает изменения,
- мейнтейнер применяет патч к следующему релизу tarball или просит внести изменения,
- повторяем процесс.
Я бы с радостью написал целый пост о том, как устроена совместная работа через почтовые рассылки, а также о её замечательных аспектах, но это уже тема для другой статьи.
Однако в таком мире системы управления версиями попросту были бесполезны — они казались шагом назад в функциональности. Они имели неуклюжие механизмы контроля доступа, они не были распределёнными и работали невероятно медленно.
Сообщество в основном работало с патчами и tarball, а существовавшие системы управления версиями были для него недостаточно хороши.
Процесс работы с патчами и tarball был своего рода первой распределённой системой управления версиями — у каждого имелась локальная копия, изменения можно было вносить локально, доступ к «мерджу» имел любой, кто мог записать новый tarball на сервер.
Однако процесс всё равно оставался довольно неудобным — нужно было возиться с патчами, помнить, что было применено и кто внёс изменения, отслеживать несколько патчей, разрешать конфликты и заниматься перебазированием.
Инструмент Bitkeeper был разработан как раз для работы над ядром; он стал попыткой создания системы управления версиями, соответствующей этому процессу, и Линусу он нравился. Однако выбранная разработчиками инструмента схема лицензирования не понравилась сообществу, для которого он был создан.
Если вы хотите больше узнать о Bitkeeper, то посмотрите этот эпизод Bits and Booze, в котором мы настраиваем его и показываем, как он использовался.
Важно понимать, что именно это стало причиной создания Git. На самом деле, он должен был стать не совсем системой управления версиями, а более совершенным способом работы с патчами и tarball — создавать снэпшот множества файлов и показывать различия, которые можно обсудить.
По большей мере, так и разрабатывалась его структура данных (связанные списки деревьев файлов и адресуемое по содержимому хранилище блобов), и эта структура фундаментально никак не поменялась с первого коммита и по сей день.
Первый коммит
Если уж мы коснулись этой темы, то как выглядел первый коммит? На что был способен Git с первого момента своего существования?
Что ж, это был дурацкий трекер контента. Линус с самого первого дня говорил так:
Это дурацкий (но чрезвычайно быстрый) менеджер содержимого папок. У него не особо много функций, но что уж он умеет делать, так это эффективно отслеживать содержимое папок.
Первый коммит был набором из семи простых автономных инструментов. Это было не что-то вроде
git commit, а очень низкоуровневые инструменты для работы с базой данных наподобие write-tree и commit-tree (такой подход изменился спустя несколько недель существования проекта, когда ко всему стал добавляться префикс git-).Некоторые из них эволюционировали в plumbing-команды, которые мы используем и по сей день, например, в
git cat-file и git write-tree, другие отличались фундаментально (например, git read-tree сегодня стала plumbing-командой Git, но первоначальная read-tree больше походила на современную git ls-files), однако на низком уровне все концепции по-прежнему существуют.По сути, в своём самом первом коммите Git мог:
- Создавать «снэпшот» при помощи
update-cacheдля сборки кэша контента (по сути, tarball) иwrite-treeдля записи объекта в базу данных. - Записывать «changeset» (коммит) при помощи
commit-tree, добавлявший комментарии об изменениях, внесённых с новым tarball, и родительский узел, на котором он был основан, чтобы подготовить историю «tarball». - Считывать эти структуры базы данных при помощи
cat-file(вытягивала объект из базы данных),read-tree(создавала список того, как выглядит кэш) иshow-diff(показывала diff кэша с рабочей папкой).
С самых первых дней проекта Линус говорил, что хочет создать все эти plumbing-инструменты, чтобы они стали бэкендом для какого-нибудь скриптового UI («porcelain») поверх них.
Лично я всегда так и видел «git»: просто как plumbing под поверхностью. Например, проекты типа arch, которые развиваются на основе «патчей и tar-ball» (думаю, в этом отношении darcs тоже на него похож), могут использовать git как гораздо более качественную «историю tarball». — Линус
Он хотел создать эффективный инструментарий для работы с базой данных истории tarball, а не настоящую систему управления версиями. Подразумевалось, что этот слой напишет кто-то другой.
Подробнее об этом чуть ниже. Ну а пока…
Скотт знакомится с Git
Лично меня познакомил с Git примерно в этот момент времени мой друг и коллега по неудавшемуся стартапу Reactrix Ник Хенгевельд.
Любопытно, что мы использовали Git примерно так, как и задумывал Линус: как распределённый трекер контента, а не как систему управления версиями.
По сути, мы работали в рекламной фирме, которая координировала дисплеи электронных табло с достаточно «тяжёлыми» по весу графическими ресурсами. Для каждого из сотен дисплеев существовала уникальная комбинация рекламных роликов; большинство из них имели медленные мобильные подключения для передачи данных, а рекламные ролики часто менялись. То есть нам нужен был способ эффективно сообщать «для машины А нам нужны ролики 1, 2 и 3 (v1). Для машины B нужны ролики 2, 3 (v2) и 4», а также инкрементно обновлять их в случае появления новых версий роликов.
Мы пользовались Git, но не для отслеживания изменений в исходном коде, а как механизм распространения контента. Был создан скрипт для изучения нового расписания, записи уникальных деревьев, содержавших только нужные для каждой машины ролики, выполнения коммита дерева в ветвь соответствующей машины. После этого машины каждую ночь выполняли скачивание и hard checkout.
Такое решение обладало рядом интересных преимуществ.
- Если рекламный ролик обновлялся, то мы передавали только изменившиеся файлы, для изменений выполнялось дельта-сжатие с тем объектом, который уже присутствовал на машине.
- Все общие ресурсы имели единый блоб, checkout которого можно было выполнять в различных контекстах. Для этого отлично подходило то, что Git работал с адресуемой по содержимому файловой системой.
- У нас были тысячи комбинаций сотен ресурсов без необходимости сохранения контента дважды и повторной передачи одних и тех же данных по сети.
Ник был довольно активным контрибьютором в проект Git на его ранних этапах, чтобы тот хорошо работал в нашем сценарии использования (он добавил в http-fetch поддержку SSL, добавил возобновляемую и параллельную HTTP-передачу, создал первое решение push на основе HTTP). Его первый патч был отправлен в сентябре 2005 года, всего спустя полгода после первого коммита Линуса.
То, что он познакомил меня с Git, мои мучения с его освоением и в итоге возникшее понимание его удобства мотивировало меня больше о нём писать и упростить обучение другим людям.
Это заставило меня составить Git Community Book, Git Internals Peepcode PDF, создать веб-сайт git-scm.com и написать книгу Pro Git. Всё это в конечном итоге привело меня в GitHub.
Легенда Git
Так как же этот дурацкий трекер контента стал самой популярной системой управления версиями в мире?
В предыдущем посте я говорил о многих причинах того, почему Git и GitHub «победили», но, вероятно, стоит вкратце сказать и о том, почему сам Git в конечном итоге оказался таким, каким мы его знаем сегодня. И, возможно, по ходу дела изложить пару забавных историй о том, как в нём возникло то, что мы знаем и любим.
Как вы могли понять из иногда недружелюбной, загадочной или несогласованной природы команд Git, он не был системой, изначально тщательно проектировавшейся с учётом удобства пользования.
В течение многих месяцев все команды git оставались невероятно низкоуровневыми — даже если вы знаете существующие plumbing-команды, то можете и не узнать ни одной из команд, существовавших на июнь 2005 года (
rev-tree, mkdelta, tar-tree?). С самого начала было довольно очевидно, что Git просто будет таким инструментарием очень низкоуровневой работы с базой данных/файловой системой, и что другие инструменты (возможно, многие) будут использовать Git в качестве своей инфраструктуры.Вероятно, чтобы избежать недопонимания, важно отделить системы управления версиями на основе git от самого git. Возможно, в будущем будут разработаны другие системы управления версиями на основе git, и у них могут быть собственные крутые названия. — Стивен Коул
Но если Линус и команда разработки раннего Git изначально не рассчитывали, что Git на самом деле станет инструментом для управления версиями, и просто хотели создать инфраструктуру, то откуда взялись porcelain-команды, которые нам известны сегодня?
Они как бы самостоятельно прокладывали себе путь в течение долгих лет, в основном в виде скриптов оболочки, написанных для удовлетворения какой-нибудь потребности.
На ранних этапах существовало множество пользовательских интерфейсов, которые при помощи скриптов превращали бэкенд-инструментарий Линуса в нечто более удобное. Самым первым и долгие годы самым популярным из них был
git-pasky, который Пётр Баудис вскоре переименовал в Cogito. Первая версия этих скриптов была выпущена через считаные дни после выпуска Git.Читая объявления о ранних релизах, можно уже ощутить возникновение инструментария, в который превратится Git.
Несколько месяцев спустя попытки разделения на porcelain и plumbing начали терпеть неудачу: инструментарий git стал конкурировать с инструментарием в porcelan-скриптах.
Эта тенденция началась, когда для повышения удобства «голого» plumbing начали добавлять команды наподобие «git diff» и «git commit». Эти базовые команды обязательно нужны, и у меня нет никаких возражений против добавления их в комплект «ядра GIT», но в то же время я думаю, что ядро не должно конкурировать с разными porcelain, и мне кажется, где-то надо провести границу. — Хунио.
В течение одного-двух последующих лет в код ядра Git продолжали проникать новые скрипты, и, наконец, стало очевидно, что оптимальнее тратить время разработчиков на работу над инструментами, распространяемыми вместе с Git, а не на то, чтобы сохранять в инструментарии это разделение на plumbing и porcelain.
В 2007 году Cogito был «выставлен на продажу», а идея о том, что какой-то porcelain будет основным способом использования Git, была более или менее забыта.
Изучая все эти коммиты и письма, написанные двадцать лет назад, интересно наблюдать за рождением инструментов, которыми многие из нас пользуются ежедневно.
▍ Первый git log
Первая версия
git log была скриптом-обёрткой, который вызывал git-rev-list --pretty и передавал его по конвейеру через pager; изначально в нём было жёстко прописано, что следует начинать с HEAD. Вот полный текст первой программы «git log»:#!/bin/sh
git-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}На случай, если вы не слышали о
rev-list, скажу, что это был простой обходчик, выводящий sha. Он по-прежнему существует: вы и сегодня можете запустить git rev-list в своём проекте.На самом деле, многие современные команды начинались с этого — скрипт оболочки или на Perl длиной в несколько строк, выполнявший команды базового plumbing. Позже ради портируемости почти всё было переписано на C как встроенные функции, но многие первые версии команд были написаны на этих скриптовых языках.
$ git-log-script
commit d9f3be7e2e4c9b402bbe6ee6e2b39b2ee89132cf
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Apr 5 12:34:56 2024 -0700
Fix bugПервый «git log» показался бы нам достаточно знакомым.
▍ Первый git rebase
Есть много разных «первых», поэтому я расскажу только о ещё одном, потому что мне он кажется интересным. Знаменитая команда «rebase» родилась из обсуждения процесса работы Линусом и Хунио в июне 2005 года.
Хунио рассказывал Линусу, каким был его рабочий процесс:
Вот, что я делал:
(1) Начинал с HEAD Линуса.
(2) Повторял цикл разработки и коммитов.
(3) Запускал «git format-patch» (не в дереве Линуса) для генерации патчей.
(4) Рассылал их и ждал, какие из них примут.
(5) Выполнял пул от Линуса.
(6) Избавлялся от своего HEAD, делая HEAD Линуса моим HEAD, сохраняя при этом изменения, внесённые мной после форка от него. Для этого я применял «jit-rewind».
(7) Изучал отклонённые Линусом патчи и применял те, которые я всё равно считал хорошими, создавая по одному коммиту на каждый патч. Для этого я использовал «jit-patch» и «jit-commit -m».
(8) Возвращался к этапу 2.
Линус ответил, что на самом деле разработчикам здесь требуется «перебазирование» работы:
Это будет чем-то похоже на текущий git-merge-script, но вместо мерджинга на основании общего родителя он будет пытаться перебазировать все локальные коммиты от общего родителя вверх к новому удалённому (remote) head. Часто это логичнее с точки зрения отдельного разработчика, желающего обновить свою работу в удалённом head.
Тогда Хунио отправил в ответ простой скрипт, использующий новую команду
git cherry для «перебазирования» серии коммитов.Насколько могу судить, это первое упоминание термина «rebase» в управлении версиями. Любопытно видеть, как рождалась история.
▍ Как «осьминог» стал частью Git?
Меня много раз спрашивали, откуда в GitHub взялся «Octocat»; ответ тоже можно найти в этих ранних архивах.
Первый раз слово «octopus» в списке рассылки Git встретилось мне, когда Хунио сказал Линусу, что его патчи применялись последовательно, а не «осьминожно» («octopus»).
Под этим подразумевалось создание merge commit с несколькими родителями, то есть другой способ мерджинга нескольких патчей. Со временем «octopus merge» стала одной из допустимых в Git стратерий мерджинга. (Забавный факт: когда-то в Git была стратегия мерджинга «stupid»).
На очень ранних этапах GitHub Том искал что-нибудь, что антропоморфически можно использовать, как тотем Git, и «Octopus» показался единственным подходящим термином из лексикона Git. Том поискал клипарт с «octopus», и рисунок Саймона Оксли показался ему самым милым. Так родился «octocat».
Будущее Git
Двадцать лет спустя кто-то может задать вопрос о том, каким будет будущее этого внезапно получившего популярность проекта.
Забавно, что я по-прежнему в каком-то смысле использую Git для того же, для чего он и задумывался. GitButler использует Git не только для создания коммитов с целью отслеживания изменений в коде, но и применяет базу данных git для отслеживания истории проекта. В конечном итоге, это всё ещё чертовски хороший дурацкий трекер контента, как и задумывал Linus.
Так что с днём рождения Git. Ты по-прежнему странный и прекрасный. И спасибо за рыбу.
Telegram-канал со скидками, розыгрышами призов и новостями IT 💻
