На этой неделе исполнятся десять лет с того момента, когда разработчики ядра Линукса столкнулись с помехой: они больше не могли использовать свою систему контроля версий BitKeeper и никакая другая система контроля исходного кода не удовлетворяла их требованиям в плане распределённости ресурсов. Линус Торвальдс, создатель Линукса, принял вызов и пропадал в течение выходных дней для того, чтобы на следующей неделе появиться с Git. Сегодня Git используется в тысячах проектов и Git подтолкнул программирование в группах разработчиков на новый социальный уровень.
Чтобы отметить эту дату, мы попросили Линуса поделиться скрытой историей создания Git, рассказать нам что он думает об этом проекте и о его влиянии на разработку программных продуктов. Вы найдёте его комментарии ниже в тексте. За этим интервью последует неделя Git, в которой каждый день мы будем рассматривать отдельные проекты, использующие эту систему контроля версий. Ожидайте истории разработки KVM, Qt, Drupal, Puppet, Wine и многие другие.
Почему ты создал Git?
Торвальдс: На самом деле, я никогда не хотел заниматься системой контроля версий (СКВ) и чувствовал что это была просто наименее интересная штука в компьютерном мире (возможно, за исключением баз данных ;^), и я страстно ненавидел все такие системы. Но тогда появился БитКипер (BK) и, действительно, изменил то, как я рассматривал контроль исходного кода. BK сделал правильно многие вещи. И возможность держать у себя локальную копию репозитория и распределённое слияние кода были хорошими штуками. Важная особенность распределённой модели контроля версий заключается в том, что она исключает одну из самых серьёзных проблем СКВ — политику того, кто может делать изменения. BK показал что ты можешь избежать это просто раздав всем репозиторий. Но BK имел и свои собственные проблемы; несколько технических решений приводили к проблемам (переименование было болезненным), но наихудшим был факт того, что поскольку BK не распространялся вместе с открытым кодом, то было и много людей, которые не хотели им пользоваться. Так что мы закончили тем, что было несколько основных разработчиков, использующих BK, который был бесплатен для использования в проектах с открытым кодом, но это никогда не стало общепринятым. Так что это (ВК) помогало в разработке ядра, но там всё равно оставались больные моменты.
Это пришло мне в голову тогда, когда Tridge (Andrew Tridgell) начал реверс-инжиниринг достаточно простого протокола BK, что было нарушением правил использования BK. Я потратил несколько недель (месяцев? Так я себя и чувствовал), пытаясь быть посредником между Tridge и Larry McVoy, но в итоге стало ясно, что это просто не работало. Итак, на каком-то этапе я просто решил, что я не могу больше продолжать использовать BK, но я также и не хочу возвращаться к худшим дням, которые были до появления BK. Грустно, что тогда были и другие инструменты для СКВ, которые в какой-то мере пытались использовать распределённую модель разработки, но ни один из них не работал хорошо в случае удалённого использования. У меня были свои требования к производительности, которые даже приближённо не могли быть удовлетворены тем, что было доступно; и я также волновался по поводу целостности кода и процесса разработки, так что я решил написать своё.
Как ты к этому подошёл? Ты писал его все выходные или только в обычное время?
Торвальдс: Эх. Вы, кстати, можете видеть как всё приняло форму в репозитории исходного кода Git, за исключением первого дня или что-то около того. День был потрачен на то, чтобы Git стал сам себя хостить так, чтобы можно было начать коммитить в Git используя Git. Поэтому первый день или что-то около того не присутствует в истории, но всё остальное — там. Основная работа была проведена, в основном, в течение дневного времени, но есть пара полуночных записей и пара — после двух часов ночи. Наиболее интересное, это то, как быстро это приняло форму. Самый первый коммит в дереве Git — это не много кода, но это делало основное — достаточное для того, чтобы закоммитить себя самого. Трюк был не столько в кодинге, сколько в том, чтобы понять как Git должен упорядочивать данные.
Я бы хотел подчеркнуть, что несмотря на то, что это было собрано в течение десяти дней или что-то вроде этого (в течение которых я сделал свой первый Git коммит в репозиторий ядра Линукса), это не было ни в какой мере сумасшедшим кодингом. Объём этого раннего кода достаточно мал, всё зависело от правильной реализации основных идей. И поэтому, я некоторое время «перемалывал» прежде чем весь проект был запущен. Я видел проблемы других. Я видел то, что я хотел избежать.
Выросло ли это (Git) до уровня твоих ожиданий? Как хорошо это (Git) работает по твоим оценкам? Есть ли какие-либо ограничения?
Торвальдс: Я очень доволен Git. Он работает исключительно хорошо с кодом ядра и по-прежнему следует моим ожиданиям. Что интересно, так это то, что он принял так много других проектов. К удивлению быстро, в конце концов. Существует много инертности в переключении от одних СКВ к другим; только взгляните как долго оставались в использовании CVS и даже RCS, но на каком-то этапе Git принял и их дела.
Как ты думаешь, почему это (Git) было так широко принят в использование?
Торвальдс: Я думаю, что многие люди были раздражены теми же самыми проблемами, которые заставили меня ненавидеть СКВ. И, хотя, было много проектов в попытке исправить одну или две мелких проблемы, которые выводили людей из себя, в действительности не существовало ничего такого как Git, что действительно помогло больше не брать больших проблем себе в голову. Даже когда люди не понимали насколько важна распределённая модель разработки (и много людей боролись с этим), то как только они осознавали, что это позволяет делать более лёгкие и надежные резервные копии и позволяет людям делать свои собственные репозитории без необходимости задумываться о политике разрешения записи в определённый репозиторий, они никогда не смотрели назад.
Будет ли Git существовать всегда или ты предугадываешь пересмотр СКВ в течение следующих десяти лет? Будешь ли ты одним из тех, кто напишет это?
Торвальдс: Нет, я не буду тем, кто это напишет. И, возможно, мы увидим что-то новое в течение десяти лет, но я гарантирую что, это будет нечто достаточно Git-подобное. Не в смысле что в Git всё правильно, но в том смысле что Git имеет основные возможности прямо внутри, которые другие СКВ ранее никогда не имели.
Без фальшивой скромности ;)
Почему Git работает так хорошо в Линуксе?
Торвальдс: Ну, Git был создан для нашей работы, потому он часть неё. Я уже упоминал распределённую модель много раз, но имеет смысл ещё раз вспомнить о ней. Но Git был также создан для того, чтобы быть достаточно эффективным для большого проекта как Линукс, и написан чтобы делать то, что люди считали сложной задачей перед появлением Git — потому что это те вещи, которые я делаю каждый день.
Просто для примера: понятие слияния рассматривалась как что-то очень болезненное и сложное во многих СКВ. Тебе бы приходилось планировать свои сливания, потому, что они были серьёзным делом. Это не устаивает меня, так как я, обычно, делаю десятки слияний в день когда нахожусь в во временном окне слияния, и даже при этом, рабочая нагрузка не должна быть в слиянии, а в тестировании кода. Слияние само по себе занимает пару секунд, гораздо больше занимает написание объяснения слияния.
Итак, Git был построен и написан для моих требований. Так и происходит.
Люди говорили что Git — только для супер умных людей. Даже Эндрю Мортон (Andrew Morton) говорил, что Git «Git спроектирован так, чтобы ты почувствовал себя ещё глупее чем раньше». Каков будет твой ответ на это?
Торвальдс: Ну я думаю, что так было сначала, но это больше не так. Есть несколько причин того, что люди так себя чувствуют, но я думаю что только одна причина осталась. Та, что осталась, очень проста: «это можно делать такими разными способами».
Можно делать много вещей при помощи Git, и многие из правил относительно того, что ты должен делать происходят не от технических ограничений, а оттого, что так работает неплохо, когда приходится взаимодействовать с другими людьми. Git является очень мощным набором инструментов, что может перегружать вначале, но это также значит, что ты можешь делать часто те же самые или похожие вещи разными путями и все они сработают. В общем, лучший способ изучить Git, вероятно, заключается в том, чтобы просто делать простые вещи и даже не смотреть на другие вещи до тех пор, пока ты не будешь уверенным в отношении основ.
Существуют несколько исторических причин для восприятия Git как сложной вещи. Одна из них — то, что это действительно было сложным. Те люди, которые начали использовать Git раньше всех для работы с ядром Линукса, действительно должны были научиться использовать достаточно непростой набор скриптов чтобы заставить всё работать. Все силы были направленны на то, чтобы заставить работать основную технологию и совсем немного — на то, чтобы сделать это легким или очевидным. Так и Git, естественно, имел репутацию которая предусматривала знание того, что ты делал ранее. Но это было, в основном, правдой только в течение первых шести месяцев или года.
Другая причина того, что люди считали, будто Git — сложная штука в том, что Git очень своеобразен. Есть люди, которые пользовались такими вещами как CVS на протяжении десятилетия или двух, и Git — не CVS. Даже не похожи. Разные концепции. Команды различаются. Git никогда не старалась выглядеть как CVS, как и наоборот. И, если ты пользовался CVS-подобной системой в течение длительного времени, то создаётся впечатление сложности и беспричинного отличия Git. Люди были оттолкнуты странной системой номеров версий. Почему номер версии Git «1.3.1», а не так как приятно сделано с увеличивающимися номерами в версиях CVS? Почему там (в Git) странный и страшный 40-символьный номер в шестнадцатеричной системе исчислений?
Но Git не был беспричинно другим. Эти отличия были нужны. Скорее всего, люди просто думают, что Git более сложен чем он есть на самом деле, просто потому, что они приходят с другим багажом опыта. Фон CVS уходит. На настоящий момент, вероятно, есть множество программистов, которые никогда не использовали CVS в своей жизни и они могут посчитать то, как работает CVS, очень запутанным просто потому, что они изучили Git в первую очередь.
Могла бы скорость разработки ядра Линукса расти с существующей скоростью без Git? Почему?
Торвальдс: Ну, «без git» — конечно. Но это бы предусматривало то, что кто-то бы написал некий эквивалент Git: некую распределённую СКВ, которая была бы также эффективна, как и Git. Мы определённо нуждались в чём-то вроде Git.
Какое твое текущее мнение о GitHub?
Торвальдс: Github является исключительным ресурсом для хостинга; у меня совсем нет ничего против него. Жалобы, которые у меня были, заключались в том, что GitHub как платформа разработки — коммиты, пулл-реквесты, отслеживание истории проблем и так далее — не работает достаточно хорошо. Это даже не близко, не походит для чего-то вроде ядра Линукса. Слишком ограниченно.
Это частично от того, как ядро Линукса разработано, но частично и потому, что интерфейсы GitHub активно стимулируют к плохому поведению. Коммиты, сделанные на GitHub содержали комментарии этих коммитов и так далее, просто потому что веб-интерфейс на GitHub активно стимулировал к плохому поведению. Они исправили некоторые из этих вещей, так что, вероятно, работает лучше, но это никогда не будет подходящим для чего-то вроде ядра Линукса.
Какое самое интересное использование Git и/или GitHub ты встречал?
Торвальдс: Я очень рад, что он (Git) так облегчил запуск новых проектов. Хостинг проекта раньше доставлял много боли, но с появлением Git и GitHub сделать любой маленький проект стало так просто. Не важно, что за проект, важно то, что ты можешь сделать.
У тебя есть побочные проекты «в рукаве»? Какие-нибудь замечательные проекты, которые будут доминировать в разработке программного обеспечения на следующие годы?
Торвальдс: Ничего не планируется. Но я дам тебе знать если эти планы поменяются.
p.s.: советы и пожелания к переводу приветствуются с целью улучшения качества перевода.
Источник:
geektimes.ru/post/248744/
