Предыдущий ролик Следующий ролик  

Видео урок: История Git

Git: обучение основам

Есть пять важных систем контроля версий, предшествующих Git, которые я хотел бы рассмотреть. Было и много других, но эти наиболее популярны и наиболее влиятельны. Первая из них - это SCCS. Она не была первой, но она стала первой популярной. Она была выпущена в 1972 и разработана AT&T, а также поставлялась бесплатно с Unix. А поскольку Unix также был бесплатным, она, как следствие, быстро распространилась по таким местам, как университеты, так что в университетах студенты обучались тому, как делать контроль версий при помощи SCCS. Так что если вы писали программы для Unix, вы скорее всего ее использовали.

И далее, когда эти студенты закончили университеты и пошли работать, системой контроля версий, с которой они были знакомы и которую они взяли с собой, была SCCS, так что теперь вы понимаете, почему она стала такой популярной. Раньше мы говорили об очень примитивных VCS, то есть у вас было нечто вроде сумки, и вы могли сохранить версию 1 сумки, и версию 2, и версию 3, каждый раз просто давая другое имя файлу. Если вы так делаете, на самом деле вы сохраняете документ три раза. Это не самый эффективный способ. SCCS же сохраняет оригинальный документ, а затем, вместо того чтобы сохранять весь документ во второй раз, она сохраняет снимок того, где были сделаны изменения.

Так что если вам нужна пятая версия документа, вы просто берете версию 1 и применяете к ней четыре набора изменений, чтобы получить версию 5. Это намного более эффективный способ сохранять каждый раз изменения. Итак, SCCS доминировала, пока в начале 80х не была разработана RCS, Revision Control System, и в ней просто было сделано много улучшений по сравнению с SCCS. Во-первых, она была кроссплатформенной, тогда как SCCS предназначалась только для Unix. С увеличением числа персональных компьютеров стало важным наличие системы контроля версий, которая могла бы работать на ПК. Она была интуитивно более понятной, имела более чистый синтаксис с меньшим числом команд, но с большим числом возможностей.

И что более важно, она была быстрее, и увеличение скорости появилось благодаря факту, что она использовала более умный формат хранения. Тогда как SCCS сохранял оригинальный файл и сохранял все изменения, которые были сделаны, RCS это обошел, так что он смог полностью сохранять наиболее поздний файл, и если вам была нужна предыдущая версия, вы могли применить снимки изменений, чтобы вернуться обратно. Если разобраться, это намного быстрее, потому что зачастую мы хотим работать с текущим документом. С SCCS если нам был нужен текущий документ и имелось 20 наборов изменений, нам нужно было взять оригинал и применить к нему 20 наборов изменений, чтобы получить нужное, С RCS мы можем просто "поднять" оригинальный файл, и он полностью сохранен.

Одна из проблем и с SCCS, и с RCS заключалась в том, что они позволяли работать за раз только с одним отдельным файлом. Так что вы могли отслеживать измения в одном файле, но не в наборе файлов или во всем проекте. CVS позволила вам сделать это, и сейчас мы говорим о Concurrent Versions System. Реальная инновация в CVS - это не только тот факт, что вы можете работать с несколькими файлами, это параллелизм, а факт, что у нас есть место, где мы храним наш код, и оно называется хранилищем кода (Code Repository). Вы можете установить его на удаленный сервер, и несколько пользователей могут работать с одним и тем же файлом в одно и то же время, они могут работать параллельно.

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

Сейчас это кажется мелким отличием, но это важно. В CVS вы бы говорили о версии 7 какого-то файла. В SVN мы говорим о файле, как он появляется в ревизии 7. SVN мог отслеживать историю директорий. Например, CVS пришлось бы туго, если бы вы переименовали файл. SVN отследил бы это изменение без проблем. Если вы добавляете файл, удаляете файл, переименовываете его, он просматривает всю директорию, чтобы увидеть, что происходит, и сделать снимок этого, тогда как CVS просто смотрит на коллекцию отдельно названных файлов.

CVS также обновлял бы файлы один за раз, когда он применял бы либо возвращался к изменениям. SVN бы сделал вместо этого транзакционный комментарий и применил бы все изменения, которые произошли в директории. Снимок был больше, чем просто отдельные файлы, он был целой директорией, целым набором изменений, которые произошли в этой директории за один раз. Это тонкое, но важное различие. Итак, SVN оставался наиболее популярной системой контроля версий в течение долгого времени, пока не появился Git, но есть другая система контроля версий, которую я бы еще хотел рассмотреть, и это BitKeeper SCM.

Это был закрытый частный инструмент управления исходным кодом. Это обозначает, что он принадлежал компании и она его продавала, так же как Adobe продает Photoshop или Microsoft продает Word. Одна из важных возможностей, которые были у BitKeeper и не у него первого, это распределенный контроль версий. Но прежде чем мы обсудим это, давайте немного поговорим о самой идее быть закрытым ресурсом, тогда как все другие, что мы недавно рассматривали, были открытыми ресурсами. Версия для сообщества BitKeeper была открытой, у нее было меньше возможностей и были некоторые ограничения, но это была версия, которую отдавали бесплатно, и эта версия использовалась для управления исходным кодом ядра Linux с 2002 до 2005.

И теперь было бы как-то неправильно использовать SCM для ядра Linux, поскольку Linux является открытым проектом, никто им не владеет, тогда как SCM принадлежит и контролируется компанией. Так что много людей возразили, сказав, а что, если в будущем они поменяют правила, и мы вдруг останемся ни с чем, потому что застряли с ПО этой компании? И представьте себе, в апреле 2005 общественная версия перестала быть бесплатной и все эти предсказания сбылись. В общем, BitKeeper никогда не был таким популярным, как CVS или SVN, но он очень важен для создания Git из-за своей связи с Linux, так как в апреле 2005, когда общественная версия перестала быть бесплатной, и родился Git. Git был создан Линусом Торвальдсом, и вы можете узнать это имя, ведь это человек, который создал Linux и до сих пор руководит разработкой Linux ядра.

Когда BitKeeper перестал быть бесплатным, появилась необходимость в альтернативе управления исходным кодом. Линус подумал, и ему не понравились другие имеющиеся VCS, как CVS и SVM. Ему нравились некоторые концепции BitKeeper, но он считал, что может создать что-то получше, поэтому он написал новую VCS с нуля. Итак, Git - это распределенный контроль версий, как BitKeeper, и в следующем ролике мы поговорим о распределенной контроли версий. Он также открыт и бесплатен, и это здорово, потому что это обозначает, что люди, как вы или я, могут скачать его бесплатно и спокойно использовать без каких-либо лицензионных ограничений или чего-то подобного.

Это также обозначает, что поскольку он является продуктом с открытым исходным кодом (open source), сообщество может видеть исходный код, а также вносить в него изменения. Поэтому мы можем фиксить баги, добавлять новые возможности, и делать все это, поскольку это проект с открытым исходным кодом. Также он совместим с большинством платформ, с Unix подобными системами и Windows, и он быстрее, чем большинство инструментов управления исходным кодом. Иногда в 100 раз быстрее для некоторых операций, и у него лучшая встроенная защита, чтобы защитить вас от кражи данных, и мы поговорим об этом немного позже. Итак, эти улучшения работали.

Git стал звездой, когда люди открыли для себя силу распределенного контроля версий, когда они прочувствовали все прекрасные возможности Git, Git получил невероятную популярность. Вообще, официальной статистики нет, но, например, GitHub был запущен в 2008, чтобы размещать хранилища исходного кода Git. В 2009 было больше 50.000 хранилищ и 100.000 пользователей. В 2011, всего лишь два года спустя, было уже 2 миллиона хранилищ и больше миллиона пользователей. Вы видите огромный скачок всего за два года.

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