Линус Торвальдс о GIT на Google Talks — различия между версиями

Текущая версия на 03:02, 24 августа 2010

Перевод доклада Линуса Торвальдса о системе контроля версий git на «Google Talk» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

Представление

Эндрю Мортон. Один из ведущих разработчиков ядра Linux. Работник Google

Эндрю: Спасибо всем пришедшим, большинство из вас вероятно уже слышали о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях. Это парень, который прется от издевательств над людьми. Его последняя выходка — создание СУВ^[2], которая явно создана для того, чтобы вы почувствовали себя менее умными, чем до знакомства с ней. Спасибо, что снизошли до нас сегодня, Линус. Последние дни я получал письма от людей, вопрошающих: «Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»

И вот, он пришел в мой офис сегодня днем, и сказал: «а чем ты вообще тут занимаешься?!» О, спасибо вам, что тратите на нас свое время. И вот, Линус пришел сегодня, чтобы объяснить нам, какого …, он написал такие тулы, гм, что только он тот избранный, кто настолько мудр, чтобы понять, как ими пользоваться.

тут все апплодируют, апплодируют…

Вводное слово

Линус Торвальдс.

Линус:

Ну, я должен слегка предостеречь вас, что я не очень хороший оратор, частично потому, что я не люблю выступать, а частично потому, что за последние несколько лет все только и хотели от меня докладов о туманном будущем Линукса в следующем столетии, а я вообще гик и предпочитаю говорить о технологиях.

Так вот, я не буду говорить про Ядро^[3], просто потому, что оно слишком большое, чтобы рассказать о нем за час, хотя похоже Эндрю сделал это пару дней назад. Вместо этого я расскажу вам про git, систему управления версиями, которую мы используем для Ядра.

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

Я не знаю, как тут у вас, на Google talks, все это происходит, я скажу просто — меня не стесняйтесь. А если ваш начальник потом вас пристрелит — это будет уже ваша проблема.

Credits

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

Сначала я хочу раздать несколько отзывов и благодарностей.

О CVS я будут отзываться только в очень-очень отрицательном ключе, потому что я, когда проектировал git, во многих ситуациях использовал (в контексте СУВ) подход «что бы тут сделал Иисус», а иногда и «что бы тут CVS никогда не сделала».

Я никогда не использовал CVS при разработке ядра. За последние десять лет для поддержки ядра мы использовали только тарболы^[4] и патчи^[5], которые оказались лучшими СУВ, чем CVS, но я «покончил с CVS» после семилетнего опыта использования ее в коммерческой компании, и я страстно ненавижу эту систему.

Когда я сказал, что страстно ненавижу CVS, я должен также сказать, что если в аудитории есть пользователи SVN (Subversion), то вы, возможно, захотите уйти. Поскольку моя ненависть к CVS означает, что я считаю Subversion самым бесцельным проектом, так как основной девиз Subversion некоторое время был «Сделанный по-уму CVS» или что-то вроде этого. А если вы начинаете с такого слогана, то вы никуда не сможете прийти. Это так, потому что CVS невозможно сделать «правильным».

Это была негативная часть.

А вот с благодарностью я упомяну о BitKeeper, хотя я понимаю, что по мнению многих, вокруг BitKeeper’а было много проблем и споров да и «развод» с ним был во многих смыслах неприятен. Но по-моему, наш развод с BitKeeper-ом был вполне полюбовный, хотя снаружи это казалось иначе. И BitKeeper не только стал первой системой контроля версий, которая показалась мне вполне достойной, но, более того, показал мне, в чем была его основная идея и как с ней можно реально работать. И хотя git во многом, в том числе технически, очень-очень сильно отличается от BitKeeper (это было специально задумано, чтобы убедить всех, что это не клон BitKeeper), многие процессы используемые нами с git, взяты из BitKeeper.

Кстати, вы используете BitKeeper здесь, в Google? Я сомневаюсь. Насколько я знаю, BitKeeper — это единственная коммерческая распределенная СУВ, и поэтому, если вам-таки нужна именно коммерческая система, то вам стоит использовать BitKeeper.

Я также хотел бы заметить, что я разрабатываю git чуть больше двух лет, но хотя я запустил проект, разработал архитектуру и начальный код, на протяжении последних полутора лет его поддерживает гораздо более славный парень, японец Junio Hamano, и именно он сделал git более доступным для простых смертных. Ранние версии git действительно требовали некоторое количество «ментальных пунктов» мозгосилы. C тех пор он стал гораздо проще.

В общем, это мой обычный подход — все остальные делают все возможное, а я сам могу просто сидеть и потягивать ПинаКоладу^[6], ну и типа люди то же вроде как-то при деле…

На этом благодарности окончены, всех вышеперечисленных откладываем в сторону.

Content

Он набросал эту презентацию прошлой ночью, не ждите здесь чуда

Вот этому слайду уже один день. Я вообще не делал презентацию прошлой ночью, потому что прошлой ночью я пьянствовал, отрывался и ел суши. Вот.

И тем не менее, в презентации речь пойдет о реализации надежной, высокопроизводительной распределенной системы управления содержимым, и ключевое слово здесь — «распределенная». Я сначала попытаюсь объяснить, почему распределенность так важна. Если мы потом к этой теме не вернемся, я буду действительно счастлив.

И ничего страшного, если мы так и не разберем, как git устроен изнутри. Учить пользоваться git’ом я тоже не буду. Ну есть же у вас такая штука, которую вы делаете, «google.com», и в ней есть такое место, куда можно вводить буквы, и если вы введете туда «git» и нажмете кнопку «Мне повезет!», вы обязательно попадете на официальный сайт git, на котором есть и вводные обучающие курсы и руководство пользователя в HTML-формате. В общем, если вы хотите научиться пользоваться git, вам нужно первым делом туда, а не на этот доклад.

Но, как я уже сказал, ничего страшного, если мы отклонимся в сторону от темы из-за ваших вопросов.

Content Advisory

Линус критичен и к программам и к людям

Я вам уже озвучил эти примечания к заголовкам; я использую сокращение SCM в значении «source code management/управление исходным кодом», что то же самое, что контроль версий. Некоторые думают, что SCM означает «Управление конфигурациями/software configuration management» и включают сюда не только контроль версий, но и управление релизами и все такое; но я сейчас буду рассказывать не об этом, хотя git вполне подходит и для этого.

С CVS мы уже разобрались. Вы можете не соглашаться со мной сколько хотите, но в течение этого доклада все, кто не согласен со мной, по определению — тупые уроды. Помните об этом! Вы будете вольны делать и думать все что захотите, когда я закончу доклад. А сейчас я рассказываю свое единственно правильное мнение, так что пользователи CVS, если вы действительно его так любите, уйдите с глаз моих долой. Вам надо обратиться в психушку или куда-то еще.

Background

от BitKeeper к git

Теперь, перед тем как начать говорить о самой сути «Распределенности», что, по-моему, архиважно, нельзя не упомянуть об истории git, потому что если люди что-то и слышали о git, то это, в первую очередь, историю его возникновения.

Во-первых, я на самом деле вообще не фанат SCM. Я никогда особо не интересовался системами контроля версий, и думал, что это зло, пока не наткнулся на BitKeeper, который оценил по достоинству; и, в некотором смысле, именно поэтому git намного лучше всего остального, ведь мой мозг не страдал долгие годы, думая, что CVS делает что-либо разумное.

Мне понадобилась замена для BitKeeper. Причина в том, что BitKeeper — это коммерческий продукт, но BitMover и Larry McVoy разрешили использовать его бесплатно для open-source продуктов, как вы, возможно, знаете; единственным ограничением было то, что его нельзя было исследовать (reverse engineer) и нельзя пытаться создать конкурирующий продукт.

И я был вполне этим доволен, ведь я делаю свободное ПО, потому что считаю это единственным правильным способом разработки, но я также хочу использовать лучшие инструменты для работы, и BitKeeper был как раз таким.

Но не все были согласны со мной. Все они тупые уроды, но как бы там ни было, они подкинули проблем, и это в результате привело к тому, что мы с Larry несколько раз поговорили по телефону и в конце концов договорились прервать сотрудничество, дабы не ухудшать отношения.

Тогда, примерно 2 года назад, я выпустил релиз Linux 2.6.12-rc2 и сказал, что не продолжу разработку Linux, пока у меня не будет замены BitKeeper’у, для управления исходным кодом.

Одним из способов замены был возврат к tar-архивам и патчам, но все были категорически против.

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

Если система не распределенная, ее не стоит использовать, это же очевидно.

Если у системы проблемы с производительностью, ее тоже не стоит использовать, это так же очевидно. И наконец, если вы не можете быть уверенными в том, что то, что вы положите в SCM, можно легко достать обратно в том же виде, такую систему тоже лучше не использовать.

Честно говоря, та малышка [BitKeeper] прекрасно заботилась обо всем. Полно СУВ которые не гарантируют, что то, что вы из них достаете, является в точности тем, что в них положили. Вы можете никогда и не узнать, что у вас повреждена память или жесткий диск. А заметите это, только когда получите назад поврежденный файл. Причем сама система контроля версий за этим вообще не следит. И такое — совсем не редкость. Да, это встречается очень, очень часто.

Проблема быстродействия: одной из систем, которая мне более-менее понравились, была система Monotone, о которой, кстати, когда-то вроде был доклад в Google, хотя может я и ошибаюсь; так вот, в ней было много интересных идей, но производительность была просто ужасна, так что попробовав ее один день, я понял, что она мне не подходит.

В результате, я решил, что сам за две недели смогу написать что-то получше, и не ошибся.

Distribution

[Показывает слайд «Distribution» с картинкой]

Это не просто хорошая идея. По-другому просто не будет работать!

Теперь перейдем к Распределенности, и это худший слайд из всех, и мне стыдно за него, но проблема в том, что Распределенность действительно очень важна, но у меня никогда не получается сделать об этом нормальный слайд. Частично это из-за моих скудных художественных способностей, которые вы видите перед собой на экране, но на самом деле это действительно трудно объяснить.

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

[слушатели поднимают руки]

Большинство из вас разрабатывают ядро? Нет? Хорошо, примерно десять человек подняли руки.

Распределенность главным образом означает отсутствие центрального места, в котором хранятся ваши данные и отслеживаются изменения. Ни одно хранилище не является более важным, чем какое-либо другое.

Поэтому, например, я Subversion даже трехметровым багром трогать не буду. В Subversion большой репозиторий, куда все обязаны складывать свои данные. А централизованная модель просто не работает, когда… давайте взглянем на некоторые такие случаи.

[Показывает слайд «Distribution» с пунктами]

Слайд «Distribution» с пунктами

Я сказал, что распределенность — это гораздо больше, чем просто работа в оффлайн, но это, пожалуй, понять проще всего: вы можете взять по-настоящему распределенную SCM с собой в самолет и, даже если в нем нет ни Wi-Fi, ни спутникового интернета, вы просто продолжаете работать — вы можете посмотреть любые логи, вы можете фиксировать изменения, вы можете делать все, что вы бы делали, если бы вы были подключены прямо к магистральному каналу с гигабитным Ethernet. И это действительно важно.

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

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

И это действительно очень важно и очень сильно отличается от работы в CVS, где ветвление считается уделом настоящих мастеров.

Кто из вас когда-либо пользовался CVS?

[Слушатели поднимают руки]

Понятно, все. А кто когда-нибудь по-настоящему создавал ветку, а потом объединял изменения в CVS?

[Слушатели поднимают руки]

Хорошо. Отмечу, что далеко не все, хотя и гораздо больше, чем я ожидал.

Ну и кому из вас понравилось осуществлять этот процесс?

[смех]

Понятно, все-таки нескольким понравилось.

Считается, что это сложная операция. В CVS, когда вы объединяете ветки (а я делал это, избегал как мог, но приходилось), вы планируете это на неделю вперед и, как правило, оставляете на это целый день.

Разве я не прав? Что-то я не вижу, чтобы многие говорили «Нет, это очень просто, мне нравится это делать». Это отвратительно!

Обязательно нужно понять, что в распределенной системе каждый человек работает со своей отдельной веткой. И это не страшно, вам даже не надо что-то специально настраивать, так устроено изначально.

На самом деле, в git мы так любим ветки, что многие держат их по 10-15 штук, потому что когда вы понимаете, что у вас по-любому будет отдельная ветка, вам уже все равно, сколько их будет, и вы делаете отдельные ветки для экспериментов и отдельные для поддержки. Так что ветвление гораздо более свойственно распределенным системам.

Еще одна вещь, которая мне кажется важной, — это то, что распределенная система в силу своего устройства более надежна.

Мой подход к архивам/бэкапам таков: не делать их специально, а просто публиковать свои данные на сайте, а остальные пусть их копируют/зеркалируют, и мне пофиг, если у меня сломается компьютер, потому что я могу скачать все обратно. И это отлично работает, и при этом мне не нужна служба поддержки.

Я очень сомневаюсь, что все так делают. Но это по-настоящему работает только в распределенных системах. Если вы пользуетесь CVS, вы не можете так сделать, если вы используете… кстати, чем вы здесь пользуетесь?

Perforce?… Perforce. Ну да, извините. Да, он, конечно же, лучше, чем CVS.

[Слушатели смеются]

Но все равно это по сути CVS.

Еще одна прикольная вещь, хотя у вас в компании возможно этого и нет, но это обязательно есть во всех командах, разрабатывающих свободное ПО, которые используют CVS или Subversion или что-то вроде этого, это то, что они пользуются понятием «commit access».

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

И что это значит? Поскольку вы не хотите, чтобы все подряд правили данные в центральном репозитории, из-за того, что большинство людей — идиоты, то вам приходится выделять людей, которые, по-видимости, идиотами не являются. И чаше всего в этой группе оказывается слишком мало людей, потому что очень сложно понять, насколько человек шарит, и наоборот, даже если эта группа будет очень мала, проблемы у вас все равно будут.

В общем, эта проблема доступа к коммитам, которую некоторые компании пытаются не замечать, просто давая всем доступ для коммитов, эта проблема создает огромный психологический барьер и в большинстве проектов с открытым кодом приходится тратить бесконечные часы для того, чтобы определиться с политикой коммитов.

Если же у вас распределенная модель, всех этих проблем нет. Доступ к коммитам есть у каждого, вы можете делать что угодно со своим проектом. Вы просто получаете собственную ветвь, и пишете ли вы в ней гениальный код, или какой-нибудь маразм, это никого не волнует, это ваша копия. Это ваша ветвь.

И потом, если окажется, что вы сделали что-то полезное, вы можете сказать людям: «Эй, тут в моей ветви все работает в десять раз быстрее, чем у всех остальных, так что ня-ня-ня, не хотите взять мой код?». И народ берет.

Так это и работает и у нас нет никаких правил. Это конечно не совсем так — у нас регулируется другое, но о таких вещах как доступ к коммитам нам беспокоиться не нужно. И я думаю, что это огромный результат и уже только из-за него одного любая система с открытым кодом должна использовать распределенную модель, а не что-либо другое.

Вы избавитесь от кучи проблем.

Одна из них касается коммерческих компаний. Распределенная модель может также помочь с процессом выпуска релизов. У вас может быть команда тестировщиков, которая работает в своем дереве. Они берут код у других, проверяют его и когда проверят, передадут его команде выпуска. И они скажут: «Эй, мы тут проверили новую версию» и разработчики могут продолжать работать головой вместо того, что маяться всякой дурью типа создания меток, ветвей и всего того, что вы обычно делаете, чтобы разработчики не конфликтовали друг с другом, потому что это достигается тем, что каждая группа работает в своем дереве, следит за тем, что она сделала и что хочет сделать.

То есть Распределенность — это на самом деле ключевой момент для любой из СУВ, которые стоит использовать.

Так что немедленно избавьтесь от Perforce!

[Апплодисменты]

Да, может и жалко, но это архиверно!

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

Из зала:

И как вы собираетесь это делать?

Вопрос. И как вы собираетесь это делать? Если у вас есть эта монстрообразная, страшно огромная база кода и вы хотите использовать ее, не останавливая другие дела на шесть месяцев, как вы собираетесь это делать?

Линус:

Не отходите от микрофона, потому что я не совсем понял ваш вопрос. Он ушел, ну ладно.

«Как вы собираетесь это делать?» — Ну, вот пример реальной распределенности: у вас есть команда из пяти человек, которые работают над одной небольшой конкретной вещью.

И это означает, что некоторое время это вещь будет сильно-сильно испорчена, так? Потому что никто на самом деле не создает прекрасный код с первого раза, за исключением меня, но я такой один, так? Поэтому им нужно иметь собственное дерево, в котором они могут работать, не мешая остальным.

Вы можете этого достичь множеством способов. В CVS один из наиболее распространенных подходов — не делать коммитов вообще, поскольку возиться с ветвями очень нудно.

То есть вы не делаете коммиты, пока код не пройдет абсолютно все тесты. Или например, в вашей компании строгое политика коммитов: «нельзя делать коммиты пока они не пройдут весь набор тестов», а между прочим все тесты будут выполняться два часа, жесть!

Да, вам не позволяют делать коммиты. И это происходит почти в каждой компании. Я уверен, что это так даже у вас, в Google. У вас вероятно есть строгий набор тестов и вам нельзя делать коммиты, пока все тесты не будут пройдены, а это приводит к тому, что на практике люди вносят изменения по одной строчке и не тестируют, потому что знают, что изменения в одной строчке скорее всего ничего не сломают. Да, бывает и так.

Такой подход, конечно — ужас-ужас! Это означает, что вы делаете коммит огромного числа изменений за раз, потому что работали над этими изменениями две недели. И в итоге у вас три человека, которые делают одно и то же, потому что они не видят изменений от других, пока не сделают коммит своих. Это часто происходит, это происходит везде, это жуть!

Другой вариант — это использовать ветви, пусть даже в централизованной среде. Но ветви всегда обрываются, так как их слишком дорого поддерживать, так что у вас не получится разрабатывать в них экспериментальную функциональность. Вы никогда заранее не знаете, потребуется ли на что-то один день или две недели, ведь почти всегда любой программист скажет: «Ха, я сделаю это за 48 часов». А потом выясняется, что «не-а, не могу».

Но так как вы думаете, что сможете сделать это за 48 часов, вам очень лень создавать ветвь, даже в таких системах, в которых это делать удобнее, чем в CVS. И вы этого не делаете, потому что думаете, что как-нибудь справитесь с этим и вы возвращаетесь к случаю № 1, но даже если вы решите создать ветвь, то будете менять содержимого репозитория и для всех остальных, потому что в централизованной среде ветви глобальны.

То есть вы столь любезны, что вы трахаетесь со всеми остальными, но при этом не трогаете их основной ствол, так называемую головную ветвь. Вы добавляете что-то новое в их репозитории, но при этом так, чтобы они ничего не заметили (по-крайней мере, вы на это надеетесь). Но общий репозиторий все равно от этого пухнет.

В общем, в любом случае, успеха вы не добьетесь.

В распределенной же среде происходит так: есть пять человек, они берут себе текущую головную ветвь, которая надежна и протестирована и они начинают работать с ней и делать коммиты, и вам не надо ждать две недели, пока ваши изменения не станут стабильными, потому что они всегда локальны. А внутри этой группы из пяти человек, все могут брать изменения друг у друга.

Вот в этом и смысл распределенности — нет центра, а значит, что все равны и что можно проводить слияния друг между другом, что можно, если хочется, не только делать коммит каждой строчки, не проходя при этом двухчасовые тесты, но и гибко взаимодействовать, забирая и сливая изменения у кого и с кем угодно, и когда кто-то находит баг и исправляет его, он говорит остальным: «Эй, у меня в репозитории лежит фикс на этот баг», и потом, когда эта группа все сделает через две недели, они позвонят менеджеру: «Эй, мы все сделали, скажи главной группе, чтоб они забрали себе обновленный код и они получат новую функциональность, и, кстати, мы его тестили больше двух недель, оно работает и с производительностью все в порядке, так как мы смогли также и профилировать этот код до того, как просить кого-либо его посмотреть».

И эта модель гораздо лучше для разработки.

И это модель, которая используется в разработке ядра Linux. Оказывается, что во многих местах нам не нужна вся эта мощь, даже в ядре. И люди обычно не обмениваются обновленным кодом внутри одной группы, но иногда случается, например, что те, кто работает над сетью, иногда сталкиваются с людьми, которые работают над NFS, и то, что они могут синхронизироваться, действительно помогает. То есть это действительно помогает!

У кого-то еще есть вопрос?

Похоже, что все эти правила и ограничения просто переместились или стали неявными.…

Из зала:

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

Линус:

Да, именно так. Но на практике вы их никогда не увидите, да там может быть тысяча или двести тысяч различных ветвей, но на практике вы никогда о них не узнаете, потому что вам это не нужно. Вы как бы будете видеть только несколько главных ветвей, может быть даже только одну.

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

Через сеть доверия.

Если вы когда-нибудь занимались какой-то работой по безопасности и не использовали концепцию сети доверия, то это был онанизм, а не работа. Я не знаю, чем вы там занимались, но поверьте мне, это единственный способ, который дает безопасность и также единственно верный подход в разработке ПО.

В своей работе я не доверяю всем без исключения.

Более того, на самом деле я крайне циничен и недоверчив.

Например, я думаю, что большинство из вас полностью некомпетентны.

Основной принцип распределенности — это то, что я не должен вам доверять. Я не должен давать вам доступ к коммитам. Но я знаю, что среди оравы середнячков есть несколько человек, достаточно выдающихся, чтобы я им доверял, ибо с ними я уже работал.

Мне нужно доверять только 5, 10, ну может 15 людям. Если у меня есть доверенная сеть, в которую входят эти 5/10/15 выдающихся человек, и я знаю, что они выдающиеся, я могу забирать новый код у них. И мне не надо париться на эту тему.

Когда Эндрю присылает мне патчи, он не использует никакого git, это в некотором роде недостаток, ну и что, он очень надежный человек. Когда он просит меня принять обновленный код, он просто посылает мне миллион патчей, я просто их применяю. Иногда я не согласен с какими-то из этих патчей, но с другой стороны, доверие означает, как это сказать… «доверять — значит прощать»? Я не знаю… В общем, это означает, что вы должны соглашаться с решениями других людей.

И самое замечательное в доверии — это что оно создает сеть. Именно здесь и появляется сеть доверия.

Мне нужно лишь несколько человек, которым я буду доверять. А у них есть другие люди, которых они выбрали, типа — «тот парнишка шарит покруче меня» — да, это хороший критерий того, от кого вам следует брать исправленный код. Если у вас есть кто-то еще, кто шарит лучше вас, — вперед. Это беспроигрышно.

Даже если окажется, что вы взяли какую-то чушь, кто-то там начнет жаловаться, вы знаете, откуда вы взяли эти исправления, и вы можете просто сказать это жалующемуся «хм, я просто скопировал это, иди к нему, он наверное знал, что делал».

Именно так я и работаю…

Именно так я и работаю, скорее всего также действуют и мои поручики/заместители ^[7]. Я забираю изменения по сетевой теме от одного человека, а он получает их от множества других людей, с которыми он постоянно работает, и таким образом все изменения приходят ко всем, и им не нужно собираться всем в одной точке.

Хотя в ядре все приходит в большей степени в одну точку, так, я думаю, сложилось исторически, и на самом деле я всегда пытался поощрять пожелания людей заводить больше деревьев, и у нас действительно есть отдельные деревья по производителям оборудования, у нас есть специальное «-mm»^[8] дерево, в котором много выделенных «точек», просто так получается, что моя точка привлекает, быть может, больше внимания, чем должна была бы.

Даже если что-то там не придет к этой одной точке, это значит, что можно взять тысячи этих ветвей, игнорируя 99.9% из них. Зато вам интересно отслеживать, скажем пять ветвей, относящихся к областям, которыми вы интересуетесь.

И все это работает очень естественно.

Одной из хороших вещей в этой целой сети доверия, является не только то, что ее легко технически реализовать, но и то, насколько легко основательно подключить к ней любого человека из этой комнаты.

Люди мыслят именно так.

Мы не знаем сотню людей. У нас есть 5, 7, 10 близких личных друзей, ну ладно, пусть мы асоциальные гики, поэтому у нас их двое, но это основы человеческого сотрудничества, то что у нас есть те, кому мы действительно можем доверять, это семья, это близкие друзья, и все это удобно и привычно, не нужно держать в голове неестественную модель взаимодействия, все подключаются естественным образом. Поэтому работа с этой моделью сетевого доверия дает огромные преимущества.

Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?

Из зала:

Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри? Похоже, тут есть вероятность «сепаратизма» в коде, так как народ, разбредется по собственным песочницам, и не будет вкладываться в основной ствол.

Линус:

Честно говоря, не так уж и много распределенных систем. Это BitKeeper, очевидно использующийся коммерческими компаниями, мы должны иметь в аудитории кого-нибудь, кто действительно знает, но что … [комментарий из аудитории], ага, HP использует такие системы как BitKeeper в проектах разработки принтеров.

Я уверен, что таких компаний немало. В мире open-source ПО, есть пара распределенных систем, которых стоит посмотреть прямо сейчас. Очевидно одна из них — git. И вы, конечно, должны выбрать ее.

Но есть и другая — Mercurial, которая на самом деле очень похожа по архитектуре. Есть некоторые различия в деталях архитектуры и большие различия в реализации, но в сухом остатке модели очень похожи. Только git делает это лучше.

Все остальное либо централизованное, либо сырое, либо слишком медленное для достаточно больших проектов.

Из зала:

А какие преимущества у компании, когда все играются в собственных песочницах?

Линус:

Я думаю, что есть полно компаний, считающих, что такие преимущества есть.

Я знаю это от инсайдеров, и не думаю, что многие компании осознанно используют git, в смысле, чтобы решение по его использованию было принято на уровне корпоративного стандарта.

Я знаю несколько компаний, которые внутри используют git, не подозревая об этом, потому что они все еще держат свои главные репозитории в Subversion, но многие разработчики затем импортируют код в git, потому что git действительно хорошо выполняет слияния. Так что вы можете взять дерево веток из Subversion, импортировать в git, позволить git сделать слияние, что было бы основной головной болью в Subversion, зафиксировать изменения и фактически экспортировать их назад в Subversion, и никто другой даже не узнает, что вы использовали git. Немного грустно, но я слышал о многих, работающих в компаниях в точности по этому сценарию.

А вот чтобы постоянно использовать git подряд в течении полугода или больше — таких людей пока еще мало.

Мы сделали масштабные улучшения пользовательских интерфейсов, честно говоря, еще год назад в коммерческих компаниях многие говорили, что его слишком трудно использовать.

Я думаю, что мы прошли переломный момент. Git намного проще использовать, чем CVS, правда-правда!

Большинство людей склоняются к … э-мнэ-э, он проще в использовании, чем что-либо еще. Это всего лишь,… забудьте это. Вы не обязаны использовать все его мощные возможности, некоторые из них могут быть тем, что вы хотели бы объяснить и представить людям только после того, как они преодолеют начальные трудности понимания того, что действительно означает распределенность, но основные вещи делать действительно легко.

Как вы сводите к минимуму конфликты слияний?

Из зала:

Одна из характеристик централизованных систем — это то, что именно тот разработчик, который должен коммитить, обязан также провести слияние. Как с этим в git? И как вы сводите к минимуму конфликты слияний?

Линус:

Спасибо, что спросили меня об этом! Это не вас ли я просил задать этот вопрос?

Одно из самых приятных свойств git это то, что он реально проще разбирается со слиянием, чем все остальные системы. Объединение ветвей в CVS происходит крайне мучительно, просто невыносимо.

По моим подсчетам ядро Линукса — это на самом деле один из крупнейших проектов с открытыми исходниками. У нас 22 000 файлов.

Мы используем git уже два года. В течение этих двух лет у нас было в среднем 4.5 слияния в день!

Если бы слияние было бы сложным, то точно пользовались чем-то другим. Так что git делает слияния простыми.

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

А другой чел поменял код так сильно и его версия настолько конфликтует с остальными (такое бывает, правда не очень часто), что я говорю: «Я мог бы это пофиксить, но мне лень». В их области я не программирую — это не моя сфера интересов, это сетевые технологии или что-то в этом духе, я просто не могу разобраться и оценить этот код, не могу его тестировать, так что просить меня разобраться с этим слиянием — просто глупо, так дела не делаются.

Ага, комп с Виндой опять погас.

Итак, помните, что распределенная модель означает, что «особенных» нет.

Поэтому вместо того чтобы самому разбираться со слиянием, я вытаскиваю первое дерево файлов, в котором не было никаких проблем, и говорю второму участнику: «Эй, я пробовал подгрузить твой код, но там была туча конфликтов со слиянием, совсем не тривиальных, так что я решил, что тебе стоит разобраться с этим самому».

И они разбираются. Они знают, что делать, потому что это их изменения.

Итак, они объединяют изменения и, вероятно, считают меня дебилом, потому что слияние для них так просто и очевидно, что я должен был принять их код с самого начала.

Зато они сами объединяют изменения, обновляют свое дерево файлов и говорят мне: «Эй, теперь можешь забирать рабочий вариант», и я загружаю себе их версию. Они прекрасно сделали всю работу за меня.

В этом-то и есть вся прелесть: они все сделали за меня. А мне достаются честь и хвала! Далее мне просто нужно подсчитать третью составляющую — PROFIT!!!

Все это аспект, естественным образом возникающий в распределенных системах, это не особенность git. Да, git справляется со слияниями гораздо проще, чем все остальные, но это свойство вытекает из самой распределенной модели.

…зачем вам так нужно иметь эту распределенную систему?

Зритель:

Слушай, я не совсем понимаю, зачем вам так нужно иметь эту распределенную систему… Ну да, вроде получаешь кучу преимуществ, по крайней мере для коммерческой разработки, да и для разработки open-source наверно очень полезно, поскольку каждый может работать сам по себе, но, когда у тебя централизованная СУВ, общая структура директорий и файлов, не окажется ли, что централизованная система с дешевыми ветками даст тот же самый эффект? Или такое просто невозможно?

Линус:

Я готов поспорить, что централизованные системы не могут работать нормально, но если у вас корпоративная среда с жестким контролем, то, действительно, централизованные системы работают лучше, и, безусловно, правда в том, что люди используют централизованные системы в течение последних 35 лет. И никто не будет спорить с тем, что централизованные системы не могут работать.

Они не могут работать так же хорошо, как и распределенные системы!

Одна из проблем состоит в том, что у централизованных систем неизбежны проблемы при совместной работе групп из разных мест.

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

Эээ… мда, я не могу показать вам демонстрацию, да и не так уж она интересна, но это ноутбук 4-5-летней давности. Что-то типа Pentium-M 1.6 GHz.

Я мог бы показать вам, что полный diff проекта Linux Kernel на этом ноуте займет чуть больше секунды.

На моей основной машине, это уже будет меньше десятой доли секунды.

Это прирост производительности, которого вы никогда не добьетесь, работая по сети.

Как только вы стали использовать сеть, хоть для пары пакетов, вы уже впустую потратили производительность.

Так что если у вас децентрализованная система, и вы привыкли делать commit или diff всего дерева исходников за 30 секунд, то, может быть, 30 секунд вам не покажутся злом.

Но поверьте, когда вы привыкли делать это за одну десятую секунды, 30 секунд — это полный отстой.

Так что, даже если вас супер сеть, всегда есть проблемы с производительностью. Не говоря уж о том, что у большинства и в помине нету хорошей сети.

Другая заморочка — это ветки. Даже если вы очень эффективно реализовали ветвления, сам факт того, что вы создаете ветки и каждый может их увидеть, потому что все централизовано, означает, что волей-неволей вам не захочется делать никаких веток.

У вас будут проблемы с пространством имен.

Как вы назовете свою ветку? Вы назовете ее «test»? Ага-ага, уже есть 5000 других веток, названных «test1», «test2», … «test5000», так что вам теперь придется выдумывать новые правила именования ваших веток, потому что у вас централизованная система с централизованным пространством имен у ветвей, что совершенно неизбежно при работе с централизованной системой.

Как же это работает в распределенной среде разработки?

Вы называете свою ветку «test», и все! Ну на самом деле, вам не следовало бы ее так называть, веткам нужно давать имена согласно их функциональности; называйте их кратко, благозвучно и конкретно — что эта ветвь делает.

Git дает вам по умолчанию одну ветку под названием «master»: красиво, коротко и ясно — это ваш основной ствол.

Но вы можете создать ветку под названием «experimental-feature-x» — и все будет понятно.

Но в централизованной среде вы просто не сможете так сделать. Вы не можете назвать ветку «experimental-feature-x». Вы должны придумывать тупые, идиотские названия.

Я работал в компании, у которой были прекрасные скрипты для CVS, настолько прекрасные, насколько это возможно, они помогали создавать ветки. Вы даже могли создать ветку с помощью одной простой команды, это не занимало много времени — система фиксировала имя вашей ветки, добавляя к ней число. Вы определяете базовое имя, говоря: «это моя ветка, она делает то-то и то-то», и система называет вашу ветвь: «то-то-и-то-то—56».

И система добавит тег/закладку там, где вы начали разрабатывать эту ветку, потому что в CVS вам приходится это делать… Это занимало некоторое время, но работало.

Вы можете так извращаться в централизованных системах, но вам не нужно этого делать!

Ваша система децентрализована, она просто работает.

Именно так все и должно работать.

Итак, я ничего не утверждаю, я не собираюсь вас убеждать переходить на децентрализованную систему, я просто констатирую факт: «Вы тупые уроды»!

Таков расклад.

Как бы то ни было, перейдем к слайду «Performance».

…сколько файлов осилит git?

Зритель:

Могу я задать вопрос?

Линус:

Давай.

Зритель:

На самом деле, два вопроса. Первый: сколько файлов осилит git? а второй, представьте, что у вас здоровенная древовидная структура файлов в git, возможно ли извлечь только часть этой структуры?

Линус:

Отличные вопросы.

На самом деле, эти вопросы цепляют совсем другую тему, хотя они связаны с производительностью.

Одно из особенных свойств git — отслеживание изменений всего содержимого, и это отличает git даже от Mercurial, несмотря на то, что они очень похожи.

Он никогда не отслеживает отдельный файл. Вы не можете прослеживать изменения файла в git.

Ну, вы можете проследить изменения проекта, в котором один единственный файл. Если в вашем проекте один файл, то у вас все получится, но если вы отслеживаете изменения в десяти тысячах файлов, то git никогда не будет возиться с ними по отдельности.

Git думает, что все вокруг — это единый проект. Вся история в git основана на истории проекта целиком.

Отсюда — важные следствия для производительности.

Когда вы используете CVS, вполне нормально, хотя и глупо, иметь один здоровенный репозиторий с миллионом файлов внутри.

Таким образом, в конце дня, поскольку CVS думает о каждом из миллиона файлов по отдельности, вы можете попросить CVS обновить только один единственный файл — все это в рамках CVS-идеологии. И это верно для множества других моментов.

Точно также работает и BitKeeper, и это является одной из его ошибок.

Проблема мышления в «концепции наблюдения за каждым файлом по отдельности» возникает очень часто, особенно, если вы разработчик высокого уровня (как я). У меня 22 тысячи файлов, и мне пофигу, что происходит с одним из них. Возможно, я буду следить за подмножеством из тысячи файлов, например, коллекцией файлов по подсистеме USB. Но я никогда не беспокоюсь о каком-то отдельном файле.

Поэтому git следит за всем, как за коллекцией файлов, и если вы попросите историю конкретного файла, git буквально начнет с глобальной истории и упростит ее. Это очень эффективная система, вам даже в голову не придет что это так, но в действительности, когда вы пытаетесь следить за миллионом файлов в репозитории, а потом просите историю конкретного файла — это очень тормозит систему. Таким образом, свойства масштабирования у git сильно отличаются от других систем, благодаря этой фундаментальной особенности.

Мы работали с большими репозиториями. Мы импортировали историю проекта KDE из SVN, может быть, не всего, но уж точно. И KDEнутые … эээ… Я не должен так их называть… Я не буду, поверьте, мне нравится KDE.

Но они засунули все компоненты в один репозиторий! Не слишком умно. Получилось так, что тот репозиторий, который, думаю, весил 8 Гб под CVS, в SVN разбух еще в три раза! Ну может там было меньше 8 Гб под CVS, но он был действительно огромным. Точно больше 4 Гб. Git же сжал это безобразие до где-то 1.3 Гб.

Итак, git очень эффективен в обработке этого проекта, почти все работает отлично, но не все и не всегда.

Система не заработает хорошо, если вы поместите миллион файлов в один репозиторий при начальном клонировании. Когда вы его запрашиваете, вы получаете его целиком. Вы сваливаете все в один репозиторий, git думает, что это один обьект. Не делайте так.

Если у вас есть множество компонентов, размещайте их в отдельные репозитории, вы можете даже создать суперпроект, в котором содержатся указатели на другие проекты, при этом что-то теряется в пользовательском интерфейсе, но вы храните разные проекты по отдельности. Тогда вы избежите проблемы «получения всего сразу». Потому что с git вам придется получить все и сразу.

Из зала: Как насчет разделяемого кода?

Линус:

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

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

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

Это похоже на модули CVS. В CVS модули не до конца индивидуальны, но это потому, что в CVS каталог — это вещь, которая всегда сама по себе, так что модуль CVS — это комбинация «каталожности» и их отслеживания, но в целом вы можете думать об этом как о модулях CVS.

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

Возможно, я забыл ответить на какую-то часть вашего вопроса.

Можно ли извлечь из репозитория только часть файлов?

Из зала:

Можно ли извлечь из репозитория только часть файлов, а не целый репозиторий?

Линус:

Вы можете экспортировать тарболы или отдельные файлы, вы можете переписать всю историю, сказав «Я хочу новую версию этого репозитория, которая содержит только эту часть», вы можете это сделать, это довольно дорогая операция, это что-то типа, импорта старого репозиторий в новый огромный репозиторий, который потом делиться на меньшие части. Вы можете это сделать, но я подчеркиваю, что следует этого избегать.

Неверно, что git не может обрабатывать большие проекты, просто производительность будет не так хороша, а вы будете иметь проблемы, которых можно было бы избежать.

Так что я пропускаю этот вопрос и возвращаюсь к теме производительности.

Performance

Одна из вещей, которую я хочу сказать по поводу производительности, это то, что, похоже, огромное количество людей, кажется, думают, что производительность это «как делать то же самое, но быстрее», а это неправда.

[показывает слайд «Производительность».]

Производительность — в первую очередь не это.

Если вы можете делать что-то действительно быстро, действительно хорошо, люди начнут использовать это по-другому.

Одна из вещей, в которой я хочу вас убедить — это то, что слияния происходят очень-очень быстро, потому что я хочу, чтобы люди сливали как можно раньше и чаще, потому что тогда это легче делать. Если вы объединяете изменения каждый день, вы никогда не попадете в неожиданную ситуацию с тяжелыми трудноразрешимыми конфликтами.

Итак, если вы действительно легко делаете ветвление и слияние, вы избегаете целого класса проблем, которые в противном случае требуют много-много времени, чтобы их избежать.

Например, давайте вернемся к одной из вещей, где, как мне кажется, разработчики Subversion показали себя полными идиотами.

Жестко сказано, правда?

Наверняка несколько из них сейчас в этой комнате.

Ну вы и тупые!

[смех]

Например, Subversion очень шумно хвалится, что они исправили CVS, сделав ветвления дешевыми. Это есть на их главной странице, где они вроде говорят, что ветвление в SVN требует O(1) операций, и что можно сделать дешевых ветвей столько, сколько хотите.

Неважно, что O(1), мне кажется, на самом деле имеет довольно большое O, но даже если ветвление занимает микросекунду, кого это волнует?

Вы меряете не то, что нужно.

Ветки полностью бесполезны, если Вы не объединяете их, а CVS не может объединить вообще ничего. Вы можете слить изменения однажды, но тогда CVS забывает то, что вы сделали, и вы никогда не сможете объединять снова, не получая адские конфликты. Слияния в Subversion — полная беда. Разработчики Subversion отчасти признают это, и у них есть некий замысел, но эти идеи тоже фигня.

Невероятно, насколько эти люди глупы. Они все время смотрели на проблему неверно. Проблема-то не в ветвлении, а в слиянии! А нормальное слияние они так за пять лет и не сделали. Вот что грустно.

Итак, быстродействие важно, но надо смотреть в корень проблемы.

Затраты на то, чтобы сделать ветку под git, буквально заключаются в создании 41-байтного файла. Ну насколько это быстро, как думаете? Не думаю, что вы даже сможете это измерить. Вы можете, в общем, если вы используете Windows, вероятно вы можете измерить это, потому что… [аудитория: смех] но как бы то ни было, это так быстро, что реально вы не сможете это измерить. И это создает ветку. Но никого это не волнует, это-то не проблема.

Единственное, что важно, это как быстро вы можете сливать изменения. В git вы можете объединить… я сливаю изменения в 22 тысячах файлов несколько раз в день, и я недоволен, если объединение занимает более пяти секунд, и все эти пять секунд загружаются в основном уходят на загрузку diffs, ладно, не diffs, а дельты между двумя деревьями, а само объединение занимает менее чем полсекунды.

И я не должен думать об этом.

Вот что длится дольше чем слияние, это то, что после каждого слияния, по умолчанию git сделает diffstat всего, что изменилось в результате объединения, потому что мне это важно. Когда я вливаю чьи-то изменения, я вроде как доверяю этим парням, но с другой стороны, вдруг они уже забросили свои лекарства? Так что я доверяю им, да, но будем говорить начистоту — может они были в порядке вчера, но сегодня был не их день… Так что для контроля я делаю diffstat и git тоже делает diffstat по умолчанию, хотя вы конечно можете для скорости его отключить, но лучше не надо, diffstat по-любому быстр, и обычно занимает…, ну если большое слияние, обычно занимает секунду-другую. Поскольку создание diff и фактически подсчет статистики о том, сколько строк изменилось — намного более затратная операция, чем выполнение непосредственно слияния.

Это вид быстродействия, который фактически изменяет ваш стиль работы. Это не улучшения быстродействия тех же действий, а возможность работать совершенно по-другому. Вот что на самом деле означает производительность, и вот почему вам не стоить смотреть ни на что, кроме git.

Hg (Mercurial) довольно хорош, но git лучше.

Я думаю, что у меня заканчивается время, мы посмотрим, есть ли еще …, … о, ОК это все еще интересно.

Мы еще не добрались до части про реализацию, но не беспокойтесь, я сейчас я много об этом расскажу: реализация очень проста.

Код и структуры данных очень-очень-очень просты. Если вы посмотрите на исходный текст и поймете, что там всего где-то 80000 строк, в основном на Cи, ну на таком Си, на котором пишу я — большинство его не понимает, но зато я комментирую код.

Исходный код может порой выглядеть сложным, потому что мы очень печемся о производительности, особенно я. Я действительно забочусь об этом, и иногда заставляю вещи работать сильно быстрее, но при этом приходится использовать более сложные алгоритмы, чем последовательная проверка файлов по очереди. Когда вы делаете слияние 22 тысяч файлов, вы не хотите проверять по одному файлу, вы хотите посмотреть все дерево сразу и сказать: «А они же одинаковые, я не должен ничего делать». В общем, git делает все такие штуки, и все это несколько раздувает объем кода, ибо по-уму все это сделать непросто, но основы все же очень и очень просты.

И одна из этих основ, это аспект безопасности и надежности.

Показывает слайд:

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

Если у вас побился диск или память, или что-то еще в этом роде — git об этом сообщит. Это даже не вопрос. Это безусловная и безоговорочная гарантия.

У вас могут быть люди, пытающиеся навредить. У них не выйдет.

Вам нужно точно знать 20 байтов 160-битного SHA-1 хеша от верхушки вашего дерева, и если вы их знаете, вы сможете доверять вашему дереву сверху донизу, всей истории целиком. У вас может быть десять лет истории проекта с сотней тысяч файлов, миллионами ревизий, но вы сможете доверять любой части любой ревизии. Потому что git такой надежный, и все его основные структуры данных очень-очень просты.

Да, мы проверяем контрольные суммы. Но мы не считаем слабую контрольную сумму, как у некоторых UDP пакетов, то есть 16-битную сумму всех байтов. Мы проверяем контрольные суммы, которые считаются криптографически стойкими.

Никто не может взломать SHA-1, но дело в том, что для git, SHA-1 это не функционал информационной безопасности, а просто проверка целостности. Безопасность там отдельно.

А то полно народу думают, что раз git использует SHA-1, а SHA-1 используется во всяком криптографическом софте, то наверно это крутая фича в безопасности. Так вот, ничего тут нет общего с безопасностью, это просто самый лучший хеш из имеющихся.

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

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

Одна из причин, по которой я так агитирую за это, состоит в том, что у нас был случай со взломом одного из сайтов BitKeeper’а, когда народ пытался испортить репозиторий с исходниками ядра, а BitKeeper отловил эту попытку. Но BitKeeper не имеет по настоящему крутого хеша, думаю, там простейший 16-CRC код, или что-то типа этого.

В принципе, это достаточно, чтобы заметить неуклюжую попытку подмены, криптографически оно ненадежно, но на практике атаки сделать уже непросто, так что тогда атака была немедленно пресечена.

Но после того, как такое случилось, когда ты уже погорел на этом, уже не хочется попасться в эту же ловушку снова.

Нет, ну может ваши проекты и не очень важные, но мои проекты точно важны, и поэтому я об этом так пекусь.

Это — также одна из причин, … вернемся на секунду к концепции распределенности …, ну, например, вы делаете ваш проект Google code, где можно держать исходники в ваших репозитариях, так вот — я бы никогда не доверил Google хранить и поддерживать мои исходники. Извините, но вы еще не заслужили моего доверия.

Причина, по которой я предпочитаю распределенные системы, состоит в том, что я могу держать свой исходный текст позади трех брандмауэров на системе, которая не позволяет даже по ssh войти. Вот здесь я не могу читать свою электронную почту, потому что моя почта идет на мою машину и единственный путь, как я могу попасть на мою машину — это когда я физически нахожусь в той сети.

Может я конечно и полностью свихнулся, может только слегка сдвинулся, но я забочусь о безопасности больше, чем большинство окружающих. Да и вообще, чтобы я дал эталонную копию репозитария исходников, о котором я так пекусь, куда-то на сторону? Абсурд!

Даже Гуглу не дам. Никогда в жизни, хоть ты меня режь.

Я позволю Google держать копию репозитория, но хочу чтобы было что-то, про что я знаю точно, что никто это не трогал.

Кстати, я не такой уж и крутой сисадмин, так что сбой на винте для меня определенно будет проблемой, так как бэкапами я не заморачиваюсь. Но все будет в порядке, если я смогу загрузить обратно данные из нескольких доверенных источников. Я смогу их сравнить друг с другом, это реально просто, я смогу сверить их хеши с теми самыми 20 байтами, о которых я очень-очень заботился — надеюсь, в нескольких местах они останутся.

20 байтов отследить легче, чем 180 МБ.

И очень маловероятно, что побьются именно эти 20 байтов.

И если у меня есть эти 20 байтов, я могу загрузить git-репозитрий даже из совершенно «левого» источника, и могу гарантировать, что они не сделали с ним ничего плохого.

Ваш проект [Google Code] — хостинг репозитариев для народа — крутое и благое дело, вот только вы неправильно делаете, если используете для него Subversion. Из-за вас люди ночами спать спокойно не будут!

Конечно, если вы делаете это для 70 … , сколько там проектов, 75 тысяч? Большинство из них довольно мелкие и ерундовые, так что все в порядке. Но если бы вы все сделали правильно, люди бы чувствовали себя получше.

У меня есть еще несколько слайдов, Но я думаю, что мы уже превысили лимит времени, и не хотелось бы грузить вас их показом, я думаю, они не очень интересны.

Небольшая иллюстрация от переводчика:

Content Management

Я уже немного говорил на тему «Полный целостный проект vs. Отдельные файлы», и что git отслеживает именно полный проект.

«Это гораздо больше чем случайный набор файлов»

Ну тут на слайде единственный пример с вызовом из командной строки, gitk — это GUI вьювер истории проекта под git, это скрипт на tcl/tk для просмотра всей той информации, которую git действительно хорошо показывает, а вот это пример командной строки, которую я использую как «мейнтейнер» высшего уровня.

Я хочу просто спросить «что изменилось с некоторой версии», или быть может «некоторой даты». Я могу легко выяснить, что поменялось «в этих двух каталогах» или «в этих двух каталогах и этом файле», и мне будет показана полная история, относящаяся к этой части репозитория.

Это более затратно, чем просто посчитать полную историю всего проекта. Если бы мой ноутбук был подключен сейчас к видеовыходу, я бы показал, что все это происходит за считанные секунды, то есть дороговато, но в целом ничего.

Этот функционал git по-настоящему уникален! Больше никто этого не может, а эта функциональность очень важна! Может быть, она и не так важна для отдельного разработчика, потому что отдельный разработчик часто думает в терминах отдельных файлов, но важно для людей, объединяющих версии проекта. Это важно для таких как я и тех, с кем я непосредственно работаю, потому что они практически никогда не заботятся об отдельных файлах, а вот такие вещи для них важны. Кто-нибудь отправляет отчеты об ошибке, которые не всегда адекватны, но пусть вам попался довольно вменяемый отчет, и вы можете сразу засечь — «Ага, это подсистема SCSI».

Вот командная строка (указывает на слайд).

Вы не можете указать точно проблемный файл, но можете сказать: «Удали последние 15 тысяч коммитов, сделанных с прошлой недели, и он откатит проект до 50 [коммитов]»

Это круто, и никакая другая система так не может, уверяю.

Вот поэтому вы и должны хотеть использовать именно git. Вот к чему это сводится. Он надежен и так безопасен, что вы можете делать то, что остальные системы или не делают, или делают очень медленно, и кроме того, он распределенный.

Итак, продолжим. Полагаю, мы можем позволить ответить на еще один вопрос. Что у нас с временем, я как-то без понятия… Ладно, давайте быстро.

…будет просто дрейф проблем с масштабируемостью…?

Слушатель:

Итак, причина ухода с Perforce — на самом деле масштабируемость и эффективность. Иначе люди просто продолжат ее использовать. И может, при переходе будет просто дрейф проблем с масштабируемостью и производительностью из одной области в другую?

Линус:

Ну я уже говорил, что я без понятия, как вы работаете с Perforce, и какие с ним проблемы, но если вы перейдете на git, вы можете быть в нем уверены, если, конечно, вы будете использовать его в разумных пределах. А эти пределы обычно достаточно очевидны. У вас есть компилятор, основные исходники, документация, ну может ваша документация разбросана как-то фрагментами, хотя наверняка у вас есть что-то типа пользовательской документации, может в Google не так, но во многих компаниях отдельно идет набор документации для потребителей и документации, сопровождающей отдельные модули и пакеты.

Так что одним из моментов использования git, о котором стоит подумать, это как организовать разумную структуру проекта. Git легко поддерживает здоровые проекты, вы можете без проблем держать в нем десятки тысяч файлов, вот в Ядре, например, их 22 тысячи. Мы тестировали на ста тысячах — и все было в порядке — git быстрей, чем что бы то ни было.

С миллионом файлов, подозреваю, другие системы, могут быть в чем-то и побыстрее. И не хотелось бы, чтобы вы попали в такую ситуацию. Но если вы правильно организуете проект и грамотно настроите, git будет и быстрее и лучше, что все остальное. Я уверен в его исключительной производительности.

Вот одна из вещей, которую мы не очень хорошо делаем, это «CVS annotate»^[9]. Люди часто используют эту команду. Я говорил, что у Perforce оно тормозит, так что вы, вероятно, хотя и не уверен, не используете Perforc’ный «annotate». Но пользователи CVS используют «CVS annotate», эту единственную операцию, которую CVS может выполнять быстрее, чем git, потому что CVS работает «пофайлово», а git — нет.

У git есть «annotate», но фактически это будет поиск, вы можете узнать об этом, если вы переместите функцию из одного файла в другой, git дословно воспроизведет историю функции, даже несмотря на перемещение. Внимание, не перемещение файла, а функцию в пределах файла он пойдет и откопает и скажет: «Эй! Эти две строки на самом деле пришли из того файла 5 лет назад».

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

В других проектах у нас есть история и подлинней, мы делали на них замеры, например, после импорта KDE и других проектов с еще более длинной историей. Тут бывают проблемы с производительностью, но все равно даже с учетом таких проблем git на один-два порядка быстрее, так что в основном беспокоиться не о чем.

И если обнаружите какую-нибудь проблему, то у нас сейчас очень-очень классное сообщество. В git-овом списке email-рассылок уровень «шума» очень мал, и хотя писем там изрядное количество, это очень вменяемый мейллист. Итак, если кто-то заинтересовался, посмотрите исходники, но начните с просмотра архива рассылки. У нас есть и свои флеймы, есть и бесцельные споры, но большинство сообщений там весьма хороши.

OK? Спасибо…

[апплодисменты]

Ссылки

1. ↑ Оригинальное видео доклада http://www.youtube.com/watch?v=4XpnKHJAok8
2. ↑ система управления версиями
3. ↑ Проект Linux Kernel.
4. ↑ tarballs — несжатые tar-архивы
5. ↑ patch — файлы изменений
6. ↑ Пинья колада (исп. Piña colada), также ошибочно называемый пинаколада/пиноколада и т. п. — традиционный карибский алкогольный коктейль содержащий ром, кокосовое молоко и ананасовый сок.
7. ↑ В оригинале lieutenants, поэтому часто в рунете помощников Линуса зовут «лейтенантами».
8. ↑ Экспериментальная ветвь ядра Linux, специализированная на управлении памятью, см. EnPedia:Mm_tree.
9. ↑ Команда, сообщающая по каждой строчке автора, совершившего в этой строчке последнее изменение и последнюю ревизию, в которой эта строчка менялась.