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

9

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

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

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

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

Марк Канлас
источник
вероятно, вы могли бы получить некоторую помощь на канале git IRC (#git на freenode)
yati sagade
2
you get the feel that it can handle many obscure workflows that other version control systems could not: Это, вероятно, потому, что оно было разработано для работы с ядром Linux, печально известным хакерским, большим и сложным фрагментом кода.
Яннис
1
На 10-й годовщине Git, вот статья из интервью с Торвальдсом: linux.com/news/featured-blogs/185-jennifer-cloer/…
Шридхар Сарнобат

Ответы:

17

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 (и сложность его командной строки).

CesarB
источник
«AFAIK, у BitKeeper также был графический просмотрщик истории». Да, это так. Это не совсем красиво, но очень функционально. См. Bitkeeper.com/Test.Using.Looking.html , хотя это плохо показывает, как отображаются ветви.
Брайан Оукли
1
Также интересное чтение, несколько избранных писем с самого начала git, показывающих немного его первоначального развития: kerneltrap.org/node/4982
CesarB
Использовали ли программисты некоторые функции git с помощью cvs + rsync + httpd? Мне было бы интересно услышать, какие домашние решения были возможны.
Шридхар Сарнобат
8

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

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

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

Майкл Боргвардт
источник
6
"Единый самый квалифицированный"? Я так не думаю. Есть много умных людей, которые имеют право писать распределенные системы контроля версий. Ребята BitMover (компания за BitKeeper) на самом деле действительно знают , что они делают. Линус даже отдает должное Ларри Маквею за то, что он показал ему, как должен работать контроль исходного кода . Без Ларри не было бы мерзости.
Брайан Оукли
1
@BryanOakley, я думаю, что мы можем избежать избиения, когда кто-то дополняет кого-то за что-то хорошее. Все знают, что это требование делает великого разработчика. Так что, если завтра вам представится большая проблема, мы можем вспомнить вас, как и Дениса Ричи. Никто не лучше другого, просто они столкнулись с требованием, признанным во всем мире, и первыми предложили решение.
Панкадж Упадхяй
2
@Bryan: я уверен, что опыт использования BitKeeper также многому научил Линуса, и я должен был упомянуть об этом. И конечно, есть много других умных, квалифицированных людей, которые знают, что они делают. Но я по-прежнему утверждаю, что опыт Линуса по поддержке ядра делает его наиболее квалифицированным и опытным. Возможно, я ошибаюсь, но можете ли вы указать на другой большой проект, в котором столько же участников, и где ответственный за него человек все еще так глубоко вовлечен в то, чтобы заставить действительный код всех этих участников работать вместе?
Майкл Боргвардт
@Pankaj Upadhyay: я никого не ругаю, я просто объясняю, почему я отказался от ответа. Вы сказали что-то о «сначала предоставил решение», что, я думаю, означает, что git был каким-то «первым» в некотором отношении. Как вы думаете, это было первым? Конечно, это был далеко не первый распространенный scm-инструмент.
Брайан Окли
1
@DeadMG: более важная часть этого утверждения появляется «... и значительная часть критична для производительности». Я сомневаюсь, что вы найдете многих, кто будет утверждать, что C не очень хорошо подходит для реализации высокопроизводительного кода с низкими издержками, если вы хорошо его знаете.
Майкл Боргвардт
6

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

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

Грэм Борланд
источник