Find file
Fetching contributors…
Cannot retrieve contributors at this time
61 lines (37 sloc) 5.93 KB

Ранее

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

We have better technologies now

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

Мир без VCS

Для начала давайте представим жизнь в которой нет системы контроля версий. Как бы мы жили в таком случае? Как организовали бы свою работу?

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

Резервные копии

Если бы не было VCS я бы после каждой существенной правки делал backup своих исходников. Т.е. в каждой папке (или архиве) хранилось бы состояние моего проекта в какой-то момент времени.

Описание последовательности работы

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

Оптимизация хранения

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

  • хранить только изменившиеся файлы

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

  • отделяем файлы от мета-информации: дерево проекта

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

  • Отделяем файлы от мета-информации: дерво изменений

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

Давайте посмотрим на приблизительную схему того что получилось

Структура коммита

Коммит — это наша «запись в журнале изменений», он состоит из текстового описания, автора вносимых изменений, указателя на родительский коммит (коммиты), и указателя на состояние дерева в этом коммите. По этим ссылкам, как мы уже рассмотрели ранее нашу поделку, мы можем восстановить состояние дерева проекта в любое интересующее нас время.

Всё это и делает git

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

Работа с git — работа с графом

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

Все смотрим интерактивную демнострацию ;)

Полезные ссылки

git для детей от 4х