Как был разработан Git?

Мое рабочее место недавно переключилось на Git, и я люблю (и ненавижу!) Это. Я действительно люблю это, и это очень сильно. Единственная часть, которую я ненавижу, - то, что иногда это слишком сильно (и, возможно, немного кратко / запутанно).

Мой вопрос ... Как был разработан Git? Просто используя его в течение короткого промежутка времени, вы чувствуете, что он может обрабатывать многие непонятные рабочие процессы, которые не могут другие системы контроля версий. Но он также чувствует себя элегантно внизу. И быстро!

Это, без сомнения, отчасти для таланта Линуса. Но мне интересно, был ли общий дизайн git основан на чем-то? Я читал о BitKeeper, но в аккаунтах мало технических деталей. Сжатие, графики, избавление от номеров ревизий, выделение ветвлений, копирование, удаленность ... Откуда все это?

Линус действительно выбил его из парка и с первой же попытки! Это довольно хорошо использовать, когда вы пройдете обучение.

Git не был разработан так, как развился .

Посмотрите сами. Клонируйте официальный репозиторий git , откройте его gitk(или ваш любимый графический просмотрщик журнала git) и посмотрите его самые ранние ревизии.

Вы увидите, что изначально он имел только основные функции (объектную базу данных и индекс). Все остальное было сделано вручную . Однако это небольшое ядро ​​было разработано так, чтобы его можно было легко автоматизировать с помощью сценариев оболочки. Первые пользователи git написали свои собственные сценарии оболочки для автоматизации общих задач; постепенно эти скрипты были включены в дистрибутив git (см. более ранний пример 839a7a0 ). Каждый раз, когда возникала новая потребность, сценарии адаптировались к ней. Намного позже, некоторые из этих сценариев будут переписаны на C.

Эта комбинация чистого, ортогонального ядра (которое вы все еще можете использовать напрямую, если у вас есть такая необходимость) с верхним слоем, органически выросшим над ним, - вот что дает git его силу. Конечно, это также то, что дает ему большое количество команд и опций со странными именами.

Сжатие, графики, избавление от номеров ревизий, выделение ветвлений, копирование, удаленность ... Откуда все это?

Многое этого не было в начале.

Несмотря на то, что каждый объект был сжат по отдельности, а дублирование было предотвращено путем присвоения им имен, «пакетных» файлов, которые отвечают за высокое сжатие, которое мы привыкли видеть в git, не существует. Сначала философия гласила: «Дисковое пространство дешево».

Если под «графиками» вы имеете в виду графических зрителей gitk, они появились позже (AFAIK, первым был gitk). AFAIK, BitKeeper также имел графический просмотрщик истории.

Избавившись от номеров версий, на самом деле основная концепция git, заключающаяся в использовании файловой системы с адресным содержимым для хранения объектов, в основном исходила из монотонности . В то время монотонность была медленной; если бы это было не так, возможно, Линус использовал бы его вместо создания git.

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

Stashing ( git stash), IIRC, совсем недавно. Reflogs, которые он использует, не было там в начале.

Даже пультов там не было изначально. Первоначально вы скопировали объекты вручную, используя rsync.

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

Я думаю, что главное в том, что git был разработан самым квалифицированным человеком на планете для этого. И я не говорю о таланте, я говорю об опыте: я сомневаюсь, что есть кто-то еще, кто отвечал за кодовую базу с сопоставимой комбинацией размера и количества участников, как ядро ​​Linux, и все еще фактически имеет дело с большей частью интеграции работать сам.

Таким образом, Линус знал требования и варианты использования для распределенной системы контроля версий лучше, чем кто-либо другой. И, конечно, помогло то, что большая часть кода, который он имел в виду, была написана на C, а большая часть критична по производительности.

По сути, это лучший пример того, как чесаться.

Он был разработан в точности так, как описано в Притче о Git .

Представьте, что у вас есть компьютер, на котором нет ничего, кроме текстового редактора и нескольких команд файловой системы. Теперь представьте, что вы решили написать большую программу на этой системе. Поскольку вы являетесь ответственным разработчиком программного обеспечения, вы решаете, что вам нужно изобрести какой-то метод отслеживания версий вашего программного обеспечения, чтобы вы могли получить код, который вы ранее изменили или удалили. Далее следует история о том, как вы могли бы разработать одну из таких систем контроля версий (VCS), и причины такого выбора.