Мережнітехнології-2its.kpi.ua/subjects/34/documents/Лек_Системы...Все...

Лекция 2Системы контроля версий

Штогрина Елена Сергеевна

Мережні технології-2Технології інтернет

Предназначение систем контроля версий

Проблема

Контроль версий осуществляется копированием файлов в другой каталог, как правило добавляя текущую дату к названию каталога.

случайное изменение не тех фалов, или изменение файлов не в том каталоге

либо копирование файлов не туда, куда надо было, и в

результате затирание нужных файлов.Нет информации о том, что изменяется от

версии к версии.

Определение

Система управления версиями (от англ. Version Control System (VCS) или RevisionControl System) — программное обеспечение для облегчения работы с изменяющейся информацией.

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

Функции системы контроля версийхранение несколько версий одного и того же

документа (история версий);

хранение истории разработки;

при необходимости возвращение к более ранним версиям документа (отмена изменений);

определение, кто и когда сделал изменение (поиск «виновного»);

совмещение изменений сделанных разными разработчиками (синхронизация работы команды);

реализация альтернативных/эксперементальныхвариантов проекта.

Области применения систем контроля версий

Разработка программного обеспечения - хранение исходных кодов разрабатываемой программы.

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

(Software Configuration Management Tools). В САПР, обычно в составе систем управления данными

об изделии (Product Data Management (PDM)).

Как пример - Википедия ведёт историю изменений для всех её статей, используя методы, аналогичные тем, которые применяются в системах управления версиями.

История систем контроля версий

Типы систем контроля версий

Локальные системы контроля версий

Пример: rcs.

Централизованные системы контроля версий

Пример: CVS, Subversion и Perforce.

Децентрализованные системы контроля версий

Пример: Git, Mercurial, Bazaar, Darcs.

Типы систем контроля версий Блокирующие — позволяют наложить запрет на изменение

файла, пока один из разработчиков работает над ним.

Не блокирующие — один файл может одновременно изменяться несколькими разработчиками.

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

Для бинарных данных (важна возможность блокировки).

Локальные системы контроля версий

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


Позволяют сотрудничать разработчиками.

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

Централизованные системы контроля версийПреимущества:

все знают, кто и чем занимается в проекте;

у администраторов есть чёткий контроль над тем, кто и что может делать,

Недостатки:

централизованный сервер является уязвимым местом всей системы: если сервер не работает, то разработчики не могут взаимодействовать, и

никто не может сохранить новой версии своей работы;

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

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

Распределённые системы контроля версий

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


Преимущества:

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

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

Обзор систем контроля версий(http://all-ht.ru/inf/prog/p_0_1.html)

RCS - система управления пересмотрами версий

www.gnu.org/software/rcs/rcs.htmlО системе:

Одна из первых систем контроля версий – RCS (Revision Control System – система управления пересмотрами версий), разработанная в 1985 году. Она пришла на смену популярной в то время системы контроля версий SCCS (Source Code ControlSystem – система управления исходным кодом).

На данный момент RCS активно вытесняется более мощной системой контроля версий CVS, но все еще - достаточно популярна, и является частью проекта GNU.

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

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

Преимущества:

1. RCS - проста в использовании и хорошо подходит для ознакомления с принципами работы систем контроля версий.

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

3. Широко распространена и предустановленна в большинстве свободно распространяемых операционных системах.


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

2. Не позволяет одновременно вносить изменения в один и тот же файл несколькими пользователями.

3. Низкая функциональность, по сравнению с современными системами контроля версий.

Выводы:

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

CVS - система управления параллельными версиямиwww.nongnu.org/cvs Система управления параллельными версиями (Concurrent Versions System) – логическое развитие системы управления пересмотрами версий (RCS),

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

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

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

Достоинства: 1. Несколько клиентов могут одновременно работать над одним и тем же проектом. 2. Позволяет управлять не одним файлом, а целыми проектами. 3. Обладает огромным количеством удобных графических интерфейсов, способных удовлетворить практически любой, даже самый требовательный

вкус. 4. Широко распространена и поставляется по умолчанию с большинством операционных систем Linux. 5. При загрузке тестовых файлов из репозитория передаются только изменения, а не весь файл целиком.

Недостатки: 1. При перемещении или переименовании файла или директории теряются все, привязанные к этому файлу или директории, изменения. 2. Сложности при ведении нескольких параллельных веток одного и того же проекта. 3. Ограниченная поддержка шрифтов. 4. Для каждого изменения бинарного файла сохраняется вся версия файла, а не только внесенное изменение. 5. С клиента на сервер измененный файл всегда передается полностью. 6. Ресурсоемкие операции, так как требуют частого обращения к репозиторию, и сохраняемые копии имеют некоторую избыточность. Выводы: Несмотря на то, что CVS устарела и обладает серьезными недостатками, она все еще является одной из самых популярных систем контроля версий и

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

Система управления версиями Subversionwww.subversion.tigris.org Subversion – эта централизованная система управления версиями, созданная в 2000 году и основанная на технологии клиент-сервер. Она обладает всеми достоинствами CVS и решает основные ее

проблемы (переименование и перемещение файлов и каталогов, работа с двоичными файлами и т.д.). Часто ее называют по имени клиентской части – SVN.

Принцип работы с Subversion очень походит на работу с CVS. Клиенты копируют изменения из репозитория и объединяют их с локальным проектом пользователя. Если возникают конфликты локальных изменений и изменений, сохраненных в репозитории, то такие ситуации разрешаются вручную. Затем в локальный проект вносятся изменения, и полученный результат сохраняется в репозитории.

При работе с файлами, не позволяющими объединять изменения, может использоваться следующий принцип:

1. Файл скачивается из репозитория и блокируется (запрещается его скачивание из репозитория).

2. Вносятся необходимые изменения.

3. Загружается файл в репозиторий и разблокируется (разрешается его скачивание из репозитория другим клиентам).

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

Однако, и у Subversion есть недостатки.

Достоинства:

1. Система команд, схожая с CVS.

2. Поддерживается большинство возможностей CVS.

3. Разнообразные графические интерфейсы и удобная работа из консоли.

4. Отслеживается история изменения файлов и каталогов даже после их переименования и перемещения.

5. Высокая эффективность работы, как с текстовыми, так и с бинарными файлами.

6. Встроенная поддержка во многие интегрированные средства разработки, такие как KDevelop, Zend Studio и многие другие.

7. Возможность создания зеркальных копий репозитория.

8. Два типа репозитория – база данных или набор обычных файлов.

9. Возможность доступа к репозиторию через Apache с использованием протокола WebDAV.

10. Наличие удобного механизма создания меток и ветвей проектов.

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

12. Широкое распространение позволяет быстро решить большинство возникающих проблем, обратившись к данным, накопленным Интернет-сообществом.


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

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

3. Слабо поддерживаются операции слияния веток проекта.

4. Сложности с полным удалением информации о файлах попавших в репозиторий, так как в нем всегда остается информация о предыдущих изменениях файла, и непредусмотрено никаких штатных средств для полного удаления данных о файле из репозитория.

Выводы:

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

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

Система управления версиями Aegiswww.aegis.sourceforge.net Aegis, созданная Питером Миллером в 1991 году, является первой альтернативой централизованным системам управления версиями. Все

операции в ней производятся через файловую систему Unix. К сожалению, в Aegis нет встроенной поддержки работы по сети, но взаимодействия можно осуществлять, используюя такие протоколы, как NFS, HTTP, FTP.

Основная особенность Aegis – это способ контроля вносимых в репозиторий изменений. Во-первых, перед занесением каких-либо изменений, они должны обязательно пройти ряд тестов. И если нововведения в исходный код

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

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

не сильно это облегчает.

Достоинства: 1. Надежный контроль корректности загружаемых изменений. 2. Возможность предоставлять различные уровни доступа к фалам репозитория, что дает приличный уровень безопасности. 3. Качественная документация. 4. Возможность переименовывать файлы, сохраненные в репозитории, без потери истории изменений. 5. Возможность работы с локальным репозиторием, если отсутствует сетевой доступ к главному репозиторию. Недостатки: 1. Отсутствие встроенной поддержки сетевого взаимодействия. 2. Сложность настройки и работы с репозиторием. 3. Слабые графические интерфейсы. Выводы:Сложность работы Aegis может оттолкнуть пользователей от использования систем контроля версий, поэтому ее нельзя рекомендовать для ознакомления или ведения небольших программных проектов. Однако, она имеет ряд преимуществ, которые могут быть полезны в некоторых специфических ситуациях, особенно, когда требуется жесткий контроль за качеством разрабатываемого программного обеспечения.

Система управления версиями Monotonemonotone.ca Monotone – еще одна децентрализованная система управления версиями, разработанная Грейдоном Хоэм. В ней каждый клиент сам отвечает за синхронизацию

версий разрабатываемого продукта с другими клиентами.

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

Работа с Monotone строится следующим образом. В первую очередь, создается база данных проекта SQLite, и генерируются ключи с использованием алгоритма хеширования SHA1 (Secure Hash Algorithm 1).

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

Для синхронизации проекта с другими пользователями необходимо:

- Экспортировать ключ (хэш - код последней версии проекта) и получить аналогичные ключи от других клиентов.

- Сохранить всем клиентам полученные ключи в связке ключей своих локальных проектах Monotone.

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


1. Простой и понятный набор команд, схожий с командами Subversion и CVS.

2. Поддерживает переименование и перемещение файлов и директорий.

3. Качественная документация, значительно облегчающая использование системы контроля версий.


1. Низкая скорость работы.

2. Отсутствие мощных графических оболочек.

3. Возможные (но чрезвычайно низкие) совпадения хэш - кода отличных по содержанию ревизий.

Выводы:

Monotone - это мощный и удобный инструмент для управления версиями разрабатываемого проекта. Набор команд - продуман и интуитивно понятен, особенно, он будет удобен для пользователей, привыкших к работе c Subversion и CVS. Прекрасно оформленная и полная документация позволит быстро освоиться и использовать все возможности Subversion на полную мощность.

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

Система управления версиями Mercurialmercurial.selenic.com Распределенная система контроля версий Mercurial разрабатывалась Мэттом Макалом параллельно с системой контроля версий Git, созданной

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

Первоначально, она была создана для эффективного управления большими проектами под Linux’ом, а поэтому была ориентирована на быструю и надежную работу с большими репозиториями. На данный момент mercurial адаптирован для работы под Windows, Mac OS X и большинство Unixсистем.

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

Идентификация ревизий происходит на основе алгоритма хеширования SHA1 (Secure Hash Algorithm 1), однако, также предусмотрена возможность присвоения ревизиям индивидуальных номеров.

Так же, как и в git’е, поддерживается возможность создания веток проекта с последующим их слиянием.

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

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


1. Быстрая обработка данных.

2. Кросплатформенная поддержка.

3. Возможность работы с несколькими ветками проекта.

4. Простота в обращение.

5. Возможность конвертирования репозиториев других систем поддержки версий, таких как CVS, Subversion, Git, Darcs, GNU Arch, Bazaar и др.


1. Возможные (но чрезвычайно низкие) совпадения хеш - кода отличных по содержанию ревизий.

2. Ориентирован на работу в консоли.

Выводы:

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

Система управления версиями Bazaarbazaar.canonical.com Bazaar – распределенная, свободно распространяемая система контроля версий, разрабатываемая при поддержке компании Canonical Ltd. Написана на языке

Python и работает под управлением операционных систем Linux, Mac OS X и Windows.

В отличие от Git и Mercurial, создаваемых для контроля версий ядра операционной системы Linux, а поэтому ориентированных на максимальное быстродействие при работе с огромным числом файлов, Bazaar ориентировался на удобный и дружественный интерфейс пользователя. Оптимизация скорости работы производилось уже на втором этапе, когда первые версии программы уже появились.

Как и во многих других системах контроля версий, система команд Bazaar’a - очень похожа на команды CVS или Subversion, что, впрочем, неудивительно, так как обеспечивает удобный, простой и интуитивно понятный интерфейс взаимодействия с программой.

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

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


1. Кросплатформенная поддержка.

2. Удобный и интуитивно понятный интерфейс.

3. Простая работа с ветками проекта.

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

5. Великолепная документация.

6. Удобный графический интерфейс.

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


1. Более низкая скорость работы, по сравнению с git и mercurial, но эта ситуация постепенно исправляется.

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

Выводы:

Bazaar – удобная система контроля версий с приятным интерфейсом. Хорошо подходит для пользователей, которых отталкивает перспектива работы с командной строкой. Множество дополнительных опций и расширений позволит настроить программу под свои нужды. Схожесть системы команд с Git и Subversion, и возможность работы напрямую с их репозиториями, - сделает переход на Bazaar быстрым и безболезненным. Об успешности базара говорит и тот факт, что ей пользуются разработчики Ubuntu Linux.

Система управления версиями Arch Arch – распределенная система контроля версий, созданная Томом Лордом.

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

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

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

Не требует специального сервиса для сетевого репозитория и может использовать такие протоколы, как FTP, SFTP или WebDAV и так далее.

Но, к сожалению, поддерживается только UNIX – системами, однако, перевод Arch под другие операционные системы не должен составлять труда.

Трудно отметить какие то принципиально лучшие качества, по сравнению с другими распределенным системами контроля версий, такими как git, mercurial, bazaar, так что если есть выбор, то лучше использовать что-то более мощное и распространенное.

Система управления версиями Perforcewww.perforce.com Коммерческая программа. Централизованная система контроля версий – Perforce, разработанная

компанией Perforce Software.

Система Perforce имеет клиент-серверную организацию и позволяет одновременно управлять несколькими проектами, создавая для каждого проекта свой репозиторий.

Perforce – кроссплатформенная система. Существуют версии, способные работать под управлением операционных систем Unix, Mac OS X, Microsoft Windows.

Для работы с системой контроля версий можно использовать, как консоль, так и специально разработанный графический интерфейс.

Серьезное преимущество Perforce’у дает возможность интегрироваться со множеством средств разработки программного обеспечения и такими приложениями, как Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs и многими другими.

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

Система управления версиями Team Foundation Servermsdn.microsoft.com/en-us/library/ms364061.aspx Собственно говоря, нельзя назвать Team Foundation Server (TFC) просто системой контроля версий – это некое комплексное

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

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

TFC легко интегрируется с Microsoft Excel и Microsoft Project, что значительно облегчает создание и отслеживание элементов контролируемых проектов.

В качестве системы контроля версий, TFC позволяет:

- совместно корректировать файлы проекта;

- разрешать конфликты;

- создавать ветки проектов, а затем объединять их;

- управлять доступом к репозиторию;

- откатываться на предыдущие версии;

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

- помечать отдельные версии файлов в репозитории и группировать их;

Для сохранения данных и репозиториев разрабатываемых проектов используются базы данных SQL Server 2005.

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

Система управления версиями Gitwww.git-scm.com С февраля 2002 года для разработки ядра Linux’а большинством программистов стала использоваться система контроля версий BitKeeper. Довольно долгое время с ней не возникало проблем, но в 2005 году Лари МакВоем

(разработчик BitKeeper’а) отозвал бесплатную версию программы.

Разрабатывать проект масштаба Linux без мощной и надежной системы контроля версий – невозможно. Одним из кандидатов и наиболее подходящим проектом оказалась система контроля версий Monotine, но Торвальдса Линуса не устроила ее скорость работы. Так как особенности организации Monatone не позволяли значительно увеличить скорость обработки данных, то 3 апреля 2005 года Линус приступил к разработке собственной системы контроля версий – Git.

Практически одновременно с Линусом (на три дня позже), к разработке новой системы контроля версий приступил и Мэтт Макал. Свой проект Мэтт назвал Mercurial, но об этом позже, а сейчас вернемся к распределенной системе контроля версий Git.

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

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

Часто при работе с Git создают центральный репозиторий, с которым остальные разработчики синхронизируются. Пример организации системы с центральным репозиторием – это проект разработки ядра Linux’a(http://www.kernel.org).

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

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

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


1. Надежная система сравнения ревизий и проверки корректности данных, основанные на алгоритме хеширования SHA1 (Secure Hash Algorithm 1).

2. Гибкая система ветвления проектов и слияния веток между собой.

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

4. Высокая производительность и скорость работы.

5. Удобный и интуитивно понятный набор команд.

6. Множество графических оболочек, позволяющих быстро и качественно вести работы с Git’ом.

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

8. Широкая распространенность, легкая доступность и качественная документация.

9. Гибкость системы позволяет удобно ее настраивать и даже создавать специализированные контроля системы или пользовательские интерфейсы на базе git.

10. Универсальный сетевой доступ с использованием протоколов http, ftp, rsync, ssh и др.


1. Unix – ориентированность. На данный момент отсутствует зрелая реализация Git, совместимая с другими операционными системами.

2. Возможные (но чрезвычайно низкие) совпадения хеш - кода отличных по содержанию ревизий.

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

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

Выводы:

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

Базовые термины


Репозиторий(repository, depot), сервер —хранилище, хранит все исходные коды программы, а также историю их изменений.

Клиент - имеет свою локальную копию (working copy) исходных кодов, с которой работает разработчик.

Базовые терминыРабочая (локальная) копия документов (working

copy)(check-out, clone) — извлечение документа из хранилища и создание рабочей копии.

Изменениея (changeset, activity) — набор изменений, проименованный набор правок, сделанных в локальной копии для какой-то цели.

Ревизия (revision) — версия документа, новые изменения (changeset) создают новую ревизию репозитория.


Метка (tag, label) — пометка начала отсчета изменений в дереве, групирует несколько файлов в пригодный для использования блок. Чаще всего используется для обозначения конечной версии файлов для сборки.

head — самая свежая версия (revision) в хранилище.

Слияние версийТри вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений:

1. Обновление рабочей копии (update, sync) - изменения, сделанные в основной версии, сливаются с локальными, происходит синхронизация рабочей копии до некоторого заданного состояния хранилища (в т.ч. и к более старому состоянию, чем текущее).

2. Фиксация изменений (Коммит (check-in, commit, submit)) -локальные изменения сливаются с изменениями, уже зафиксированными в основной версии.

Описание коммита — описание того, что сделано.

3. Слияние ветвей (merge, integration) - объединение независимых изменений в единую версию документа - изменения, сделанные в одной ветви разработки, сливаются с изменениями, сделанными в другой.

Слияние версийИзменения:

модификация содержимого файла;

создание нового файла или каталога;

удаление нового файла или каталога;

переименовании ранее существовавшего файла или каталога в проекте.

Механизм автоматического слияния изменений основывается на принципе:

Если два изменения относятся к разным и не связанным между собой файлам и/или каталогам, они всегда могут быть объединены автоматически.

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


Конфликт (conflict) — ситуация, когда при слиянии нескольких версий сделанные в них изменения пересекаются между собой.

Конфликты и их разрешение

Конфликтующими обычно являются:

Удаление и изменение одного и того же файла или каталога.

Удаление и переименование одного и того же файла или каталога (в случае, если система поддерживает операцию переименования).

Создание в разных версиях файла с одним и тем же именем и разным содержимым.

Изменения в пределах одного текстового файла, сделанные в разных версиях, если они пересекаются.

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

Конфликты и их разрешение

Необходимо участие разработчика для разрешения конфликта.

Разработчику предлагается три варианта конфликтующих файлов:

базовый,

локальный,

серверный.

Блокировки – механизм разрешения конфликтов

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

Пример необходимости использования блокировок - работа с бинарными файлами, для которых нет инструментальных средств слияния изменений либо такое слияние принципиально невозможно (как, например, для файлов изображений).


Патч (patch) — файл, описывающий различие между файлами.

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

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

Способы хранения версийGit считает хранимые данные набором слепков небольшой файловой системы. При фиксации текущей версии проекта, Git сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл.


Ветвь (branch) — направление разработки, независимое от других. Представляет собой копию части хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви.

Используются:

при групповом режиме работы;

для уменьшения риска потери изменений при локальных авариях;

для обеспечения возможности анализа и возврата к предыдущим вариантам кода.

Ветвление Ветвь представляет собой копию части (как правило, одного

каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви.

Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные — после неё.

Изменения из одной ветви можно переносить в другую.

Обычно ветвь реинтегрируется в ствол (основную ветвь).

Если изменения порождают новый вариант проекта, который далее развивается отдельно от основного ветвь может остаться самостоятельной.

Пример эволюции ветвей в проекте

Ветвление – хорошая практика разработки

Главные ветки:

Ствол (trunk, mainline, master) — основная ветвь разработки проекта.

Develop

Ветка Master

•Создается при инициализации репозитория.

•В любой момент времени в в ней должен быть только

Production-Ready код.

•Считается главной, интеграционной.

•Когда код в ветке develop становится пригодным для

релиза, его интегрируют в master и помечают тегом

версии.

Дополнительные ветки

Ветки функциональностей (Feature branches)

Ветки релизов (Release branches)

Ветки исправлений (Hotfix branches)

Ветки функциональностей (Feature branches)

1. Могут порождаться от develop.

2. Должны интегрироваться в develop.

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

4. Существуют столько, сколько разрабатывается функция(feature).

5. Как правило существует в репозиторииразработчиков, а не в центральном.

Ветки релизов (Release branches)

1. Могут порождаться от develop.

2. Должны интегрироваться в develop, master.

3. Название: release-*.

4. Используются для подготовки версий к релизу.

Ветки исправлений (Hotfix branches)1. Могут порождаться от master.

2. Должны интегрироваться в develop, master.

3. Название: hotfix-*.

Похожи на релизные ветки, отличие в том, что они не запланированные.

Создаются в момент, когда необходимо срочно исправить ошибку в Production-Ready коде.

Команда может работать над develop версией, а в это время в ветке исправлений кто-то пытается быстро устранить найденную ошибку.

Пример эволюции ветвей в проекте

Последовательность работы над проектом

Начало работы с проектом - извлечение рабочей копии проекта или той его части, с которой предстоит работать

- команды извлечения версии (checkout или clone)

Ежедневный цикл работы:

1. Обновление рабочей копии.

2. Модификация проекта.

3. Фиксация изменений.

Базовые принципы разработки ПО в VCS

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

Общие принципы правильного использования VCS

1.

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

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

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


2.

Текущая версия главной ветви всегда корректна.

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

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


3.

Любое значимое изменение должно оформляться как отдельная ветвь.

Промежуточные результаты работы разработчика фиксируются в эту ветвь.

После завершения работы над изменением ветвь объединяется со стволом.

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


4.

Версии проекта помечаются тегами.

Выделенная и помеченная тегом версия более никогда не изменяется.

Практическая работа с системами контроля версийGIT

Ежедневный цикл работы с GitОбновление репозитория и рабочей копии

git pull

Добавление файла в проект

git add newFile.cpp

Коммит

git commit –m “описание того, что сделано”

Передача изменений во внешний репозиторий

git push

TortoiseGit

VisualStudio•

gitk•

Git полезные ссылки

http://git-scm.com/book/ru/

http://githowto.com/ru

Сервисы, предоставляющие хостинг для git-репозиториев

GitHub https://github.com/

Codebase

SourceForge

Gitorious

Google Code http://code.google.com/intl/ru-RU/

Bitbucket https://bitbucket.org/ - предоставляет бесплатные«закрытые» репозитории

GitHub GitHub – это самый большой веб-сервис для хостинга проектов и совместной их

разработки. Его называют «социальной сетью для разработчиков».

Сервис основан на системе контроля версий Git, а разработан на Ruby on Rails и Erlang.

Сервис бесплатен для open source проектов и предоставляет им все возможности, в том числе и SSL. Для частных проектов предусмотрены различные тарифные планы.

Слоган сервиса – «Social Coding» (Пишем код вместе) Талисманом Github является осьмикот, который ничего не означает, а просто был

найден разработчиком Томом Престон-Вернером на фотобанке и сочтен забавным.

Первый частный репозиторий был создан 12 января 2008 года. На конце прошлого года проект уже насчитывал 1 миллион участников и более 2 миллионов репозиториев.

Многие крупные проекты размещают свои официальные репозитории на сервисе. Среди них: Facebook, Twitter, Yahoo, Ruby on Rails, PHP, JUnit, jQuery, Microsoft IronRuby, osCommerce.

Bitbucket

Bitbucket («ведро битов») — веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git.

По назначению и предлагаемым функциям аналогичен GitHub(однако GitHub не предоставляет бесплатные «закрытые» репозитории, в отличие от Bitbucket), который поддерживает Git и Subversion.

Bitbucket поддерживает OpenID.

Слоган сервиса — «We’re here to serve» (Мы здесь, чтобы служить).

Нумерация версий программного обеспечения


Версия программы может быть:

целым числом (Corel Draw 11, );

дробным числом (Windows 3.11);

последовательностью чисел (JDK 1.0.3, Skype 6.6.0.106);

годом (Windows 2000);

текстом (Embarcadero Delphi XE);

Пример:

Adobe Photoshop CS6 v13.1.2

Торговое название Внутренняя версия


Критерии выбора системы версионирования:

Поддержка той или иной системы со стороны ПО для разработки(компилятора, системы контроля версий и т. д.)

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

всеобъемлющее тестирование (пример: Microsoft Word 97 SP2»;

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

Степень совместимости сетевых протоколов, документов или надстроек сторонних разработчиков. например, «старшая» версия увеличивается с каждым изменением ABI(Application Binary

Interface) или API(Application Programming Interface).

Маркетинговые соображения.

Формат номера версии

A.B.C.D[r]

A – главный номер версии (major version number).

B – вспомогательный номер версии (minor version number).

C – номер сборки, номер логической итерации по работе над функционалом версии A.B (build number).

D – номер ревизии, сквозной номер назначаемый автоматически программным обеспечением хранения версий (SVN).

[r] – условное обозначение релиза.

Формат номера версии

A.B.C.D[r] A.B (главный номер версии + вспомогательный номер версии )

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

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

C (номер сборки) Обычно увеличивается руководителем проекта по разработке, когда продукт передаётся на

тестирование.

D (номер ревизии ) Увеличивается системой контроля версий (SVN) автоматически при работе с ней. Номер ревизии SVN должен синхронизироваться с номером ревизии в AssemblyInfo при каждой

сборке релиза (revision number). Эта операция выполняется одновременно с увеличением номера билда (С).

[r]

Стадии разработки программного обеспечения

Используются для описания степени готовности программного продукта.

[r] – условное обозначение релиза.


Пре-альфа (Pre-alpha (pa)) Начальная стадия разработки.

Характеризуется большими изменениями в функционале и большим количеством ошибок.

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

Pre-alpha релизы не покидают отдела разработки ПО.


Альфа (Alpha(a)) Соответствует этапу завершения разработки нового

функционала.

Возможно добавление новых функциональных возможностей.

Стадия внутреннего тестирования. Характеризуется высокой активностью по тестированию

внутри подразделения разработки ПО и устранению ошибок.

Программы на данной стадии могут применяться только для ознакомления с будущими возможностями.

Стадии разработки программного обеспеченияБета (Beta (b)) Стадия публичного тестирования. Это первый релиз, который выходит за пределы отдела разработки ПО. Программы этого уровня могут быть использованы другими разработчиками

программного обеспечения для испытания совместимости. На этом этапе принимаются замечания от пользователей по интерфейсу

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

ошибок.

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

Beta Escrow (редко)

Стадия бета-тестирования, релиз-кандидат на Beta.


Релиз-кандидат (Release Candidate (rc))Пре-релиз — стадия-кандидат на то, чтобы стать

стабильной.

Весь функционал реализован и проведено комплексное тестирование.

Все найденные на предыдущих этапах критические ошибки исправлены.

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

На этом этапе могут вноситься изменения в документацию и конфигурации продукта.

Стадии разработки программного обеспеченияРелиз (Release to manufacturing или Release to marketing (rtm))

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

RTM не определяет способа доставки релиза (сеть или носитель) и служит лишь для индикации того, что качество достаточно для массового распространения.

RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.

Финальный релиз General availability (ga) Этап завершения всех работ по коммерциализации продукта. Продукт полностью готов к продажам через веб или на физических носителях.

End of life (eol) – работы по развитию и поддержке продукта завершены.

Пост-релиз (Post-release to manufacturing (Post-RTM)) (редко) Пост-релиз или, издание продукта, у которого есть несколько отличий от RTM и

помечается как самая первая стадия разработки следующего продукта. Такие релизы не выпускаются на продажу, а раздаются бета-тестировщикам. Это издание может быть либо стабильным (если не замечено ошибок), либо с ошибками.

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

Пакет Обновлений (Maintenance Pack (MP)) - плановый выпуск новой сборки приложения, с целью добавления новых возможностей в продукт и исправления найденных ошибок.

Мережнітехнології-2its.kpi.ua/subjects/34/documents/Лек_Системы...Все...

Documents