Первая часть интервью.
Распределенная система контроля версий Git
Дж.А.: Linux – только первая из ваших работ, глобально повлиявших на мир опенсорса. В 2005 году вы также создали Git, исключительно популярную распределенную систему контроля версий. Вы быстро перенесли дерево исходников ядра Linux из проприетарного хранилища Bitkeeper в новоиспеченный Git, который сделали опенсорсным, и в том же году передали поддержку Git Джунио Хамано. История этих событий увлекательна, расскажите, что побудило вас передать этот проект так быстро, и как вы нашли и выбрали Джунио?
ЛТ: Итак, ответ на этот вопрос состоит из двух частей.
Во-первых, я совершенно не хотел создавать новую систему контроля исходников. Linux был создан, так как мне очень интересен низкоуровневый интерфейс между аппаратным и программным обеспечением — в принципе, эта работа была выполнена из любви к предмету и личного интереса. Напротив, Git был создан из необходимости: не потому, что я интересуюсь контролем исходников, а потому что большинство имевшихся на тот момент систем контроля версий вызывали у меня подлинное отвращение, а та единственная, что показалась мне наиболее терпимой и при этом действительно весьма хорошо сочеталась с моделью разработки Linux (BitKeeper) стала несостоятельной.
Итог: я занимаюсь Linux более 30 лет (до годовщины первого релиза еще остается пара месяцев, но работать над тем, что впоследствии превратилось в Linux, я стал уже более 30 лет назад), и все это время занимаюсь его поддержкой. Но Git? Я даже не думал о том, чтобы поддерживать его в долгосрочной перспективе. Он мне определенно нравится, и я, конечно, считаю, что это наилучшая из имеющихся систем управления исходниками, но она не является моей большой любовью и увлечением, если вы понимаете, о чем я.
Поэтому я всегда хотел найти кого-то, кто поддерживал бы эту систему контроля исходников за меня; на самом деле, я был бы счастлив вообще не писать ее.
Таков контекст.
Что касается Джунио — на самом деле, он один из первых, кто реально занялся разработкой Git. Первые изменения от него пришли мне в пределах нескольких дней после того, как я выложил в общий доступ самую первую (и весьма сырую) версию Git. Поэтому Джунио причастен к этому проекту, можно сказать, с самых первых дней Git.
Но не подумайте, что я просто передал проект первому встречному. Я поддерживал Git несколько месяцев, и что побудило меня поинтересоваться у Джунио, не хочет ли он взять эту поддержку на себя — так это трудноуловимое чувство «хорошего вкуса». В самом деле, не могу описать это точнее: программирование сводится к решению технических задач, но суть в том, как вы их решаете, и это одна из тех вещей, которые начинают распознаваться со временем: определенные люди обладают «хорошим вкусом», и поэтому выбирают «правильное» решение.
Не хочу заявлять, что программирование — это искусство, поскольку на самом деле программирование — это в основном хорошая инженерия. Я глубоко верю в мантру Томаса Эдисона про «один процент таланта и девяносто девять процентов усердия»; практически вся суть успеха заключается в мелких деталях и ежедневной рутинной работе. Но, все-таки, иногда приходится проявить «вдохновение» и тот самый «хороший вкус», то есть, не просто решить задачу, а решить ее чисто, аккуратно и да, даже красиво.
Вот у Джунио такой «хороший вкус» нашелся.
Всякий раз, когда заходит речь о Git, я не забываю предельно ясно подчеркнуть следующее: пусть я и был зачинателем Git и спроектировал его ключевые идеи, зачастую я получаю за это чрезмерно много признания. Это было больше 15 лет назад, и я был по-настоящему погружен в работу над Git только в течение первого года. Джунио образцово справляется с поддержкой Git, и именно благодаря ему Git стал тем, чем является сегодня.
Кстати, вся эта история с «хорошим вкусом» и подыскиванием людей, которые им обладают, а также с умением доверять этим людям – касается не только Git, но и в не меньшей степени всей истории Linux. В отличие от Git, Linux – это продукт, чьей поддержкой я до сих пор активно занимаюсь, но, чем Linux во многом похож на Git – так это вовлеченностью огромного множества людей в проект. Думаю, одно из самых замечательных достижений Linux в том, что его поддержкой занимаются буквально сотни активных участников, и все они, отвечающие за разные части ядра, обладают этим трудноопределимым «чувством вкуса».
Дж.А.: Доводилось ли вам когда-либо делегировать кому-то поддержку, а потом понять, что это решение было ошибочным?
ЛТ: структура нашей работы по поддержке никогда не была настолько «черно-белой» или негибкой, чтобы это доставляло нам какие-либо проблемы. На самом деле, маловероятно, что мы даже когда-нибудь попытаемся тщательно документировать процедуру поддержки. Да, у нас есть файл MAINTAINERS, но он создан для того, чтобы можно было найти нужных людей, это в самом деле не знак какого-то исключительного обладания.
Поэтому вся структура «кто чем владеет» – в основном пластична и предназначена для ориентирования, означает «этот человек активен и хорошо справляется со своей работой», а не «упс, мы доверили человеку проект, а он взял и все запорол».
Ситуация пластична и в том смысле, что, может быть, вы занимаетесь поддержкой одной подсистемы, но вам что-то нужно подхватить из другой системы – так вот, эти границы проницаемы. Обычно такие вещи сначала активно обсуждаются с людьми, а лишь потом делаются, но суть в том, что такая практика есть, и не существует жестких правил вроде «вам можно прикасаться только к этому файлу».
Фактически, здесь мы вновь затрагиваем тему лицензирования, поднятую в первой части, и подчеркиваем один из принципов, по которым спроектирован Git, а именно «у каждого есть собственное дерево, и технически ни одно дерево не является особенным».
Поскольку во многих других проектах использовались такие инструменты как CVS или SVN – фундаментально некоторые люди действительно становятся особенными и пользуются «обладанием», которое приходит вместе с этим статусом. В мире BSD этот феномен называется «бит подтверждения» (commit bit): это разряд, обладатель которого имеет право фиксировать код в центральном репозитории (или, как минимум, некоторых его частях).
Я всегда терпеть не мог такую модель, поскольку она неизбежно сказывается на политике и порождает в сообществе разработчиков «клику», когда некоторые люди становятся привилегированными, и им по умолчанию доверяют. Проблема даже не в том, что «по умолчанию доверяют», а как раз в другой стороне медали: кому-то, другим людям, не доверяют, и они по определению оказываются аутсайдерами, которым для выполнения работы нужно пройти кого-то из «охранителей».
Опять же, в Git такой ситуации не возникает. Все равны. Каждый может клонировать ветку, начать собственную разработку, и, если они хорошо справятся с работой, то при объединении их ветка может вернуться в основную, а если очень хорошо – то им поручается поддержка, и именно они начинают отвечать за слияние кода в тех деревьях, за которые отвечают ;).
Поэтому не приходится наделять людей особыми привилегиями, таким «битом подтверждения». Это также означает, что не возникает политики, связанной с коммитами, не приходится никому «по умолчанию доверять». Если оказалось, что кто-то плохо справился с работой, либо, что чаще, человек просто охладел к проекту и нашел дело поинтереснее – их наработки не попадут в основную ветку при объединении, и они не будут путаться под ногами у других, кто может предложить новые, свежие идеи.
Дж.А.: Впечатляли ли вас когда-нибудь новые возможности Git, включали ли вы их в свои рабочие процессы? Можете ли назвать такие фичи, которых, на ваш взгляд, в Git до сих пор не хватает?
ЛТ: разумеется, в первую очередь были удовлетворены именно мои пожелания по функционалу, поэтому мне редко приходилось задумываться о каких-либо новых фичах.
С годами Git определенно улучшился, и некоторые такие подвижки отразились и на моих рабочих процессах. Например, Git всегда работал весьма быстро — в конце концов, это была одна из целей, которые я поставил при проектировании, но значительная часть работы исходно делалась в виде шелл-скриптов, организованных вокруг некоторых базовых вспомогательных программ. С годами большая часть этих шелл-скриптов ушла, это означает, что я могу применять комплекты патчей от Эндрю Мортона даже быстрее, чем это делалось изначально. Это очень радует, поскольку именно скорость работы с патчами я использовал в качестве одного из первых контрольных показателей при тестировании производительности.
Итак, для меня Git всегда был хорош, но со временем стал только лучше.
Значительные улучшения связаны с тем, насколько удобнее стало «обычным пользователям» работать с Git. Во многом благодаря тому, что люди разобрались, как в Git устроен поток задач, и просто привыкли к нему (он очень отличается от CVS и других аналогов, к которым люди привыкли ранее), но и сам Git стал гораздо приятнее в использовании.
Облачные серверы от Маклауд быстрые и безопасные.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
