Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное
Учреждение высшего профессионального образования
«ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ» (ТУСУР)
Кафедра радиотехнических систем (РТС)
Курсовая работа
по курсу «Информационные технологии»
СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ
Студенты гр.121-3 Королев Д.О.,
Кулешов М.В., Садов Д.А., Таймасов С.С.
Руководитель Ноздреватых Б.Ф
Курсовая работа 46с., 31 рис., 2 табл., источников.
СИСТЕМА КОНТРОЛЯ ВЕРСИЙ, GIT, SVN, MERCURIAL.
В данной курсовой работе рассматриваются наиболее популярные системы контроля версий.
Цель работы - познакомится с системами контроля версий, разобраться в их работе, установке и настройке.
В процессе работы производилась установка трех видов систем контроля версий с их настройкой и тестированием работы.
В результате три полностью готовые к работе системы контроля версий, составлены таблицы сравнения функций этих систем и приведен словарь терминов, используемых при работе с программами.
Курсовая работа выполнена в текстовом редакторе Microsoft Word 2010 и представлена в печатном и электронном виде.
контроль версия система интерфейс
Введение
3.1 Начало работы с проектом
3.2 Ежедневный цикл работы
3.3 Ветвления
3.4 Слияние версий
3.5 Конфликты и их разрешение
3.6 Блокировки
3.7 Версии проекта, теги
4.1 Локальные системы контроля версий
4.2 Централизованная модель
5.1.1 Требования к системе
5.1.2 Концепция
5.1.3 Начало работы
5.2.1 Требования к системе
5.2.2 Установка
5.2.3 Основная концепция
5.2.4 Создание хранилища
5.2.5 Импорт проекта
5.2.7 Внесение изменений
5.2.8 Добавление новых файлов
5.2.9 Отмена изменений
5.3.1 Требования к системе
5.3.2 Концепция
5.3.3 Начало работы
Заключение
Приложение А
Приложение Б
Приложение В
Введение
Сегодня в мире, где существует огромное количество сложных систем, существует необходимость видоизменения электронных документов на различных стадиях их разработки. За время своего существования электронный документ может быть подвержен большому количеству изменений. Однако часто так бывает, что для дальнейшей работы необходима не только последняя версия документа, но и различные предыдущие варианты.
Безусловно, можно хранить несколько различных вариантов необходимого документа, но данный способ неэффективен. Нам приходится тратить кучу времени и сил, необходимо особое внимание и велика вероятность ошибки. Кроме того нам приходится хранить огромное количество практически идентичных документов.
Вследствие этого были разработаны программные средства, которые упрощают данный механизм. Данные средства именуются системами контроля версий. Существует несколько систем такого рода, каждая из которых актуальна при определенных условиях их использования.
Основная идея систем контроля версий - запоминать все внесенные изменения, а так же комментарии пользователей, их вносивших. После этого становится понятно кто, когда и что менял, зачем и почему. И, что немаловажно, все эти изменения можно потом откатить на любой момент времени.
В соответствии с поставленной целью необходимо решить следующие задачи:
Определить понятие системы контроля версий;
Понять, как работают такие системы;
Рассмотреть правила установки и запуска;
Проанализировать существующие системы контроля версий;
Рассмотреть основные виды данного рода систем.
Задачи работы предопределили ее структуру. Курсовая работа состоит из пяти глав, введения, заключения, списка литературы и приложения.
1. Понятие системы контроля версий
Система контроля версий (СКВ) -- программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение.
2. Использование системы контроля версий
Такого рода системы в большинстве своем используются при разработке программного обеспечения, чтобы можно было хранить исходные коды разрабатываемых программ. СКВ позволяет разработчикам хранить прошлые версии файлов из разработки и доставать их оттуда. Она хранит информацию о версии каждого файла (и полную структуру проекта) в коллекции, обычно называемой репозиторием. Но, тем не менее, данные системы могут использоваться и в других областях знаний, которые включают в себя огромное количество часто изменяющихся электронных документов. Например, они всё чаще применяются в САПР, обычно, в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления.
Использование СКВ, безусловно, обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков.
Системы контроля версий решают следующие проблемы:
Хранение версий файлов;
Возможность получить любые предыдущие версии хранимых файлов;
Просмотр изменений внесенных между заданными в запросе версиями;
3. Типичный порядок работы с системой
Каждая СКВ имеет свои специфические особенности в наборе команд, порядке работы пользователей и администрировании. Тем не менее, общий порядок работы для большинства СКВ совершенно стереотипен. Здесь предполагается, что проект, каким бы он ни был, уже существует и на сервере размещён его репозиторий, к которому разработчик получает доступ.
Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо специальной команды, фактически выполняющей то же самое действие. Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.
По команде извлечения устанавливается соединение с сервером, и проект в виде дерева каталогов и файлов копируется на компьютер разработчика. Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск дополнительно записывается ещё одна его копия. Работая с проектом, разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия хранится в качестве эталона, позволяя в любой момент без обращения к серверу определить, какие изменения внесены в конкретный файл или проект в целом и от какой версии была сделана рабочая копия; как правило, любая попытка ручного изменения этой копии приводит к ошибкам в работе программного обеспечения СКВ.
При некоторых вариациях, определяемых особенностями системы и деталями принятого бизнес-процесса, обычный цикл работы разработчика в течение рабочего дня выглядит следующим образом:
1) Обновление рабочей копии. По мере внесения изменений в основную версию проекта рабочая копия на компьютере разработчика стареет: расхождение её с основной версией проекта увеличивается. Это повышает риск возникновения конфликтных изменений. Поэтому удобно поддерживать рабочую копию в состоянии, максимально близком к текущей основной версии, для чего разработчик выполняет операцию обновления рабочей копии (update) насколько возможно часто.
2) Модификация проекта. Разработчик модифицирует проект, изменяя входящие в него файлы в рабочей копии в соответствии с проектным заданием. Эта работа производится локально и не требует обращений к серверу СКВ.
3) Фиксация изменений. Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер, либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания. СКВ может требовать от разработчика перед фиксацией обязательно выполнить обновление рабочей копии. При наличии в системе поддержки отложенных изменений (shelving) изменения могут быть переданы на сервер без фиксации. Если утверждённая политика работы в СКВ это позволяет, то фиксация изменений может проводиться не ежедневно, а только по завершении работы над заданием; в этом случае до завершения работы все связанные с заданием изменения сохраняются только в локальной рабочей копии разработчика.
Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch), создание версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в основную ветвь. Это может делаться командой слияния (merge), либо путём создания патча (patch), содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.
Три вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений:
Обновление рабочей копии;
Фиксация изменений;
Слияние ветвей.
В каждой системе существует механизм автоматического слияния, который работает, основываясь на следующих принципах:
Изменения могут состоять в модификации содержимого файла, создании нового файла или каталога, удалении или переименовании ранее существовавшего файла или каталога в проекте;
Если два изменения относятся к разным и не связанным между собой файлам и/или каталогам, они всегда могут быть объединены автоматически. Их объединение состоит в том, что изменения, сделанные в каждой версии проекта, копируются в объединяемую версию;
Создание, удаление и переименование файлов в каталогах проекта могут быть объединены автоматически, если только они не конфликтуют между собой. В этом случае изменения, сделанные в каждой версии проекта, копируются в объединяемую версию.
Конфликтующими обычно являются:
Удаление и изменение одного и того же файла или каталога;
Удаление и переименование одного и того же файла или каталога;
Создание в разных версиях файла с одним и тем же именем и разным содержимым;
Изменения в пределах одного текстового файла, сделанные в разных версиях, могут быть объединены, если они находятся в разных местах этого файла и не пересекаются. В этом случае в объединённую версию вносятся все сделанные изменения;
Изменения в пределах одного файла, если он не является текстовым, всегда являются конфликтующими и не могут быть объединены автоматически.
Во всех случаях базовой версией для слияния является версия, в которой было произведено разделение сливаемых версий. Если это операция фиксации изменений, то базовой версией будет версия последнего обновления перед фиксацией, если обновление -- то версия предыдущего обновления, если слияние ветвей -- то версия, в которой была создана соответствующая ветвь. Соответственно, сопоставляемыми наборами изменений будут наборы изменений, сделанных от базовой до текущей версии во всех объединяемых вариантах.
Абсолютное большинство современных систем управления версиями ориентировано, в первую очередь, на проекты разработки программного обеспечения, в которых основным видом содержимого файла является текст. Соответственно, механизмы автоматического слияния изменений ориентируются на обработку текстовых файлов.
При определении допустимости слияния изменений в пределах одного и того же текстового файла работает типовой механизм построчного сравнения текстов (примером его реализации является системная утилита GNU diff), который сравнивает объединяемые версии с базовой и строит список изменений, то есть добавленных, удалённых и заменённых наборов строк. Найденные наборы изменённых строк, которые не пересекаются между собой, считаются совместимыми и их слияние делается автоматически. Если в сливаемых файлах находятся изменения, затрагивающие одну и ту же строку файла, это приводит к конфликту. Такие файлы могут быть объединены только вручную. Любые файлы, кроме текстовых, с точки зрения СКВ являются бинарными и не допускают автоматического слияния.
Ситуация, когда при слиянии нескольких версий сделанные в них изменения пересекаются между собой, называют конфликтом. При конфликте изменений система управления версиями не может автоматически создать объединённый проект, и вынуждена обращаться к разработчику. Как уже говорилось выше, конфликты могут возникать на этапах фиксации изменений, обновления или слияния ветвей. Во всех случаях при обнаружении конфликта соответствующая операция прекращается до его разрешения.
Для разрешения конфликта система, в общем случае, предлагает разработчику три варианта конфликтующих файлов: базовый, локальный и серверный. Конфликтующие изменения либо показываются разработчику в специальном программном модуле объединения изменений, либо просто помечаются специальной разметкой прямо в тексте объединённого файла.
Конфликты в файловой системе разрешаются проще: там может конфликтовать только удаление файла с одной из прочих операций, а порядок файлов в каталоге не имеет значения, так что разработчику остаётся лишь выбрать, какую операцию нужно сохранить в сливаемой версии.
Механизм блокировки позволяет одному из разработчиков взять только в собственное использование файл или группу файлов для внесения в них изменений. На то время, пока файл заблокирован, он остаётся доступным всем остальным разработчикам только на чтение, и любая попытка внести в него изменения отвергается сервером. Технически блокировка может быть организована по-разному. Типичным для современных систем является следующий механизм:
Файлы, для работы с которыми требуется блокировка, помечаются специальным флагом «блокируемый»;
Если файл помечен как блокируемый, то при извлечении рабочей копии с сервера он получает в локальной файловой системе атрибут «только для чтения», что препятствует его случайному редактированию;
Разработчик, желающий изменить блокируемый файл, вызывает специальную команду блокировки (lock) с указанием имени этого файла. В результате работы этой команды происходит следующее:
1. сервер проверяет, не заблокирован ли уже файл другим разработчиком; если это так, то команда блокировки завершается с ошибкой.
2. файл на сервере помечается как «заблокированный», с сохранением идентификатора заблокировавшего его разработчика и времени блокировки;
3. если блокировка на сервере прошла удачно, на локальной файловой системе с файла рабочей копии снимается атрибут «только для чтения», что позволяет начать его редактировать.
Если в процессе работы выясняется, что файл изменять не нужно, он может вызвать команду снятия блокировки (unlock, release lock). Все изменения файла будут отменены, локальный файл вернётся в состояние «только для чтения», с файла на сервере будет снят атрибут «заблокирован» и другие разработчики получат возможность изменять этот файл;
По завершении работы с блокируемым файлом разработчик фиксирует изменения. Обычно блокировка при этом снимается автоматически.
Система управления версиями обеспечивает хранение всех существовавших вариантов файлов и, как следствие, всех вариантов проекта в целом, имевших место с момента начала его разработки. Но само понятие «версии» в разных системах может трактоваться двумя различными способами.
Одни системы поддерживают версионность файлов. Это означает, что любой файл, появляющийся в проекте, получает собственный номер версии. При каждой фиксации разработчиком изменений, затрагивающих файл, соответствующая часть фиксируемых изменений применяется к файлу, и файл получает новый, обычно следующий по порядку, номер версии.
Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений приводит к увеличению этого номера. Номера версии отдельного файла здесь, фактически, не существует.
Однако оба варианта не слишком удобны. Для более удобной пометки версий проекта системы контроля версиями поддерживают понятие тегов.
Тег - это символическая метка, которая может быть связана с определённой версией файла и/или каталога в репозитории. С помощью соответствующей команды всем или части файлов проекта, отвечающим определённым условиям может быть присвоена заданная метка. Таким образом можно идентифицировать версию проекта, зафиксировав его состояние на некоторый желаемый момент. Как правило, система тегов достаточно гибкая и позволяет пометить одним тегом и не одновременные версии файлов и каталогов. Это позволяет собрать «версию проекта» любым произвольным образом.
Традиционные системы управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет бомльшую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время.
Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный -- централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё -- всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные СКВ подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё.
Такие системы используют распределённую модель вместо традиционной клиент-серверной. Они, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере, в локальном хранилище, и при необходимости отдельные фрагменты истории локального хранилища синхронизируются с аналогичным хранилищем на другом компьютере. Поэтому в случае, когда отключается сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. В некоторых таких системах локальное хранилище располагается непосредственно в каталогах рабочей копии.
Когда пользователь такой системы выполняет обычные действия, такие как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений, хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами между пользователями.
Описанная модель логически близка созданию отдельной ветки для каждого разработчика в классической системе управления версиями. Отличие состоит в том, что до момента синхронизации другие разработчики этой ветви не видят. Пока разработчик изменяет только свою ветвь, его работа не влияет на других участников проекта и наоборот. По завершении обособленной части работы, внесённые в ветви изменения сливают с основной (общей) ветвью. Как при слиянии ветвей, так и при синхронизации разных хранилищ возможны конфликты версий. На этот случай во всех системах предусмотрены те или иные методы обнаружения и разрешения конфликтов слияния.
С точки зрения пользователя распределённая система отличается необходимостью создавать локальный репозиторий и наличием в командном языке двух дополнительных команд: команды получения репозитория от удалённого компьютера и передачи своего репозитория на удалённый компьютер. Первая команда выполняет слияние изменений удалённого и локального репозиториев с помещением результата в локальный репозиторий; вторая -- наоборот, выполняет слияние изменений двух репозиториев с помещением результата в удалённый репозиторий. Как правило, команды слияния в распределённых системах позволяют выбрать, какие наборы изменений будут передаваться в другой репозиторий или извлекаться из него, исправлять конфликты слияния непосредственно в ходе операции или после её неудачного завершения, повторять или возобновлять неоконченное слияние. Обычно передача своих изменений в чужой репозиторий завершается удачно только при условии отсутствия конфликтов. Если конфликты возникают, пользователь должен сначала слить версии в своём репозитории, и лишь затем передавать их другим.
Обычно рекомендуется организовывать работу с системой так, чтобы пользователи всегда или преимущественно выполняли слияние у себя в репозитории. То есть, в отличие от централизованных систем, где пользователи передают свои изменения на центральный сервер, когда считают нужным, в распределённых системах более естественным является порядок, когда слияние версий инициирует тот, кому нужно получить его результат (например, разработчик, управляющий сборочным сервером).
Основные преимущества распределённых систем -- их гибкость и значительно бомльшая (по сравнению с централизованными системами) автономия отдельного рабочего места. Каждый компьютер разработчика является, фактически, самостоятельным и полнофункциональным сервером, из таких компьютеров можно построить произвольную по структуре и уровню сложности систему, задав желаемый порядок синхронизации.
К недостаткам распределённых систем можно отнести увеличение требуемого объёма дисковой памяти: на каждом компьютере приходится хранить полную историю версий, тогда как в централизованной системе на компьютере разработчика обычно хранится лишь рабочая копия, то есть срез репозитория на какой-то момент времени и внесённые изменения. Менее очевидным, но неприятным недостатком является то, что в распределённой системе практически невозможно реализовать некоторые виды функциональности, предоставляемые централизованными системами. Это:
Крупный распределённый проект, участники которого могут долгое время работать каждый над своей частью, при этом не имеют постоянного подключения к сети. Такой проект может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможна работа и без «групповых» серверов, тогда разработчики одной группы синхронизируют изменения между собой, после чего любой из них передаёт изменения на центральный сервер.
5. Примеры систем контроля версий
Git является распределённой системой контроля версий. В нем файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы - это изменённые файлы, отмеченные для включения в следующий коммит.
Git add ex.txt
Git commit -m "комментарий"
Git remote add origin https://github.com/Arbuz-z-z/MyHomework.git
Git push -u origin master
Команда git remote add - добавление удалённых репозиториев, а команда git push - отправление локальных изменений на удаленный сервер.
Рисунок 5.1.7
Вводим логин и пароль указанные при регистрации:
Рисунок 5.1.8
Теперь наш проект размещён на GitHub"е, в репозитории - MyHomework с файлом Tusur.txt и мы можем дать ссылку на него любому, с кем захотим разделить проект.
Рисунок 5.1.9 Репозиторий на GitHub"е
Хранилище. Subversion использует центральную базу данных, которая содержит все версированные файлы с их полной историей. Эта база данных называется хранилищем. Хранилище обычно находится на файловом сервере, на котором установлен Subversion, по запросу поставляющий данные клиентам Subversion (например, TortoiseSVN). Если вы делаете резервное копирование, то копируйте ваше хранилище, так как это оригинал всех ваших данных.
Рабочая копия. Это именно то место, где вы работаете. Каждый разработчик имеет собственную рабочую копию, иногда называемую песочницей, на своем локальном компьютере. Вы можете получить из хранилища последнюю версию файлов, поработать над ней локально, никак не взаимодействуя с кем-либо еще, а когда вы будете уверены в изменениях, вы можете зафиксировать эти файлы обратно в хранилище. Рабочая копия не содержит историю проекта, но содержит копию всех файлов, которые были в хранилище до того, как вы начали делать изменения.
Сначала создадим новую пустую директорию на ПК. Она может быть где угодно, но в этой работе мы собираемся назвать её s:\svn_repos. Теперь сделав правый клик на новой папке и в контекстном меню выберем TortoiseSVN > Создать здесь хранилище... Хранилище, созданное внутри папки, готово к использованию. Также мы создадим внутреннюю структуру папок, нажав кнопку «Создать структуру каталогов».
К хранилищу Subversion обращаются по URL-адресу, который позволяет нам указать хранилище где угодно в Интернете. В данном случае нам нужно указать на наше локальное хранилище, которое имеет URL-адрес file:///s:/svn_repos, и к которому мы добавляем имя нашего проекта TortoiseSVN.
Другая важная функция данного диалога - это окно Сообщение импорта, в которое можно добавить сообщение о том, что мы делаем. Когда нам понадобится просмотреть историю проекта, эти сообщения будут ценным подспорьем для просмотра какие изменения и когда были сделаны.
Сейчас у нас есть проект в нашем хранилище, и нам надо создать рабочую копию для повседневной работы. Стоит отметить, что импортирование папки не превращает автоматически эту папку в рабочую копию. Для создания свежей рабочей копии в Subversion используется термин «Извлечь». Мы собираемся извлечь папку TortoiseSVN из нашего хранилища в папку для разработки называемую e:\ \TortoiseSVN\svn_repos. Создадим эту папку, затем сделаем правый клик на ней и выберите пункт TortoiseSVN > Извлечь... Введите URL-адрес для извлечения, в данном случае file:///s:/svn_repos/TortoiseSVN, и кликните на OK. Наша папка для разработки заполнится файлами из хранилища.
Рисунок 5.2.5 Сравнение файлов
Теперь обновим хранилище. Это действие называется «Фиксировать изменения». Нажмём правой кнопкой на папке TortoiseSVN и выберем команду TortoiseSVN > Фиксировать. Появится диалог фиксации со списком изменённых файлов и напротив каждого будет галочка. Мы можем выбрать лишь несколько файлов из списка для фиксации.
Рисунок 5.2.6 Фиксация файлов
Во время работы над проектом, нам понадобится добавлять новые файлы, предположим мы добавили новые функции в файле и добавили справку в существующем файле. Нажмём правой кнопкой на папке и выберите команду TortoiseSVN > Добавить. Диалог добавления показывает все неверсированные файлы и мы можем выбрать те файлы, которые мы хотим добавить. Другой способ добавления файлов - это нажать правой кнопкой на самом файле и выбрать команду TortoiseSVN > Добавить.
Если мы хотим избавиться от изменений, которые мы еще не успели фиксировать и восстановить нужный файл в том виде, в котором он был перед началом изменений, то выберем команду TortoiseSVN > Убрать изменения. Это действие отменит наши изменения и вернет фиксированную версию файла, с которой мы начинали. Если же мы хотим убрать лишь некоторых изменения, то мы можете использовать инструмент TortoiseMerge для просмотра изменений и выборочного удаления измененных строк.
И вам даже не обязательно использовать именно Проводник. Контекстные меню TortoiseSVN работают во многих других файловых менеджерах, и в диалогах для открытия файлов, используемых в большинстве стандартных Windows-приложений. Однако вы должны учитывать, что TortoiseSVN изначально разработан как расширение для Проводника Windows, и, возможно, в других приложениях интеграция будет не полной, например, могут не отображаться пометки на значках.
1. На личном компьютере создается новый репозиторий (путем клонирования существующего репозитория, создания нового и т. п.);
2. В рабочей директории данного репозитория изменяются/добавляются/удаляются файлы;
3. Выполняется фиксация (commit) изменений в данный репозиторий (то есть в локальный репозиторий на личном компьютере);
4. Шаги 2 и 3 повторяются столько раз, сколько необходимо;
5. При необходимости производится синхронизация изменений с другими репозиториями: забираются (pull) чужие наборы изменений и/или отдаются (push) собственные.
То есть вся повседневная работа происходит в локальном репозитории, а когда возникает необходимость, производится отправка результатов своей работы в один или несколько других репозиториев. Количество шагов при работе с отдаленными репозиториями можно сократить, если настроить Mercurial на автоматическую отправку изменений в другие репозитории при выполнении фиксации.
Убедимся, что Mercurial видит сохраненный файл. По команде status выводится состояние рабочей копии в сравнении с состоянием локального репозитория. Mercurial показывает, что видит файл example.txt, но этот файл пока не находится в системе контроля версий (символ «?» слева от имени файла). Для того, чтобы сказать Mercurial, что его необходимо версионировать, выполним hg add. Слева от имени файла появляется символ «А», который означает что файл readme.txt будет добавлен в систему контроля версий при следующем коммите (при создании новой ревизии), который выполняется командой hg commit.
В первый раз выполнение команды hg commit может пройти неудачно. Mercurial записывает ваше имя и адрес в каждую ревизию, чтобы вы или другие пользователи могли связаться с автором каждого изменения. Чтобы установить имя пользователя следует внести изменения в расположенный в каталоге.hg внутри рабочей директории файл hgrc. Первоначальное содержание этого файла должно выглядеть примерно так:
Строка «» объявляет секцию конфигурационного файла. Вы можете прочитать «username =...» как «установить значение переменной username в секции ui». Секции продолжаются до начала новых секций. Пустые строки и строки, начинавшиеся с «#» игнорируются. Вы можете использовать любой текст в качестве значения username, так как эта информация предназначена для других людей, а не для интерпретации Mercurial"ом. В примере выше для этого использовалось распространенное соглашение: комбинация имени и адреса электронной почты.
Когда мы фиксируем изменения, Mercurial переводит нас в текстовый редактор, чтобы ввести комментарий, описывающий модификации, которые мы внесли в этом наборе изменений. Такое описание называется сообщением об изменениях (описанием изменений, описанием ревизии). Это будет записью для читателей о том, что мы сделали и почему, и будет выводиться при выполнении команды hg log после того, как мы закончим публикацию ревизии.
Mercurial игнорирует строки, начинающиеся с «HG:». Он использует их только для того, чтобы сообщить нам, изменения в каких файлах он запишет. Редактирование или удаление этих строк ни на что не повлияет. Если вы передумаете публиковать изменения во время редактирования комментария, просто выйдите из редактора без сохранения изменяемого файла. Это не вызовет изменений ни в репозитории, ни в рабочем каталоге.
Команда hg log по умолчанию выводит только первую строку описания изменений. Поэтому комментарий лучше написать так, чтобы первая строка была отделена. Для оставшейся части описания ревизии нет жестких правил. Сам Mercurial не обрабатывает и не заботится о содержимом сообщения об изменениях, хотя в вашем проекте могут быть правила, предписывающие определённое форматирование.
Хотя вы можете скопировать репозиторий как обычный каталог, лучше использовать встроенную команду Mercurial. Она называется hg clone, потому что создает идентичную копию существующего репозитория. Одно из преимуществ использования hg clone в том, что она позволяет клонировать репозитории по сети. Другим является то, что она запоминает, откуда мы его клонировали.
Каждый репозиторий Mercurial полон, самодостаточен и независим. Он содержит свою собственную копию файлов проекта и их историю. Клонированный репозиторий помнит, откуда он был клонирован, но не общается с тем репозиторием, да и ни с каким другим тоже, до тех пор пока вы ему не скажете. Следовательно, вы можете свободно экспериментировать с вашим репозиторием. Это безопасно, потому что ваш репозиторий -- «закрытая песочница», изменения в котором не повлияют ни на что, кроме него самого.
Mercurial позволяет передать изменения в другой репозиторий из репозитория, в котором мы в данный момент находимся. Добавим новую ревизию (под комментарием local change) в исходный репозиторий и выполним команду Хранилище\Синхронизация\Протолкнуть. Интерфейс рабочей среды позволяет выбрать только те ревизии, которые необходимо «протолкнуть». Обратим внимание, что в репозитории remote-vault была создана новая ветвь для полученной ревизии.
...Возможности системы контроля версий - программы, предназначенной для работы с изменяющимися документами. Ее свойства и практики использования. Внутреннее устройство хранилища. Рабочая копия версионируемых документов. Централизованные и распределённые СКВ.
презентация , добавлен 05.01.2014
Анализ методов и средств контроля доступа к файлам. Проблемы безопасности работы с файлами, средства контроля доступа ним. Идеология построения интерфейса, требования к архитектуре. Работа классов системы. Оценка себестоимости программного продукта.
дипломная работа , добавлен 21.12.2012
Анализ архитектуры ОС Windows 8. Сравнение с предыдущими версиями (интерфейс Modern UI, работа с учетными записями, модель безопасности, диспетчер задач, история файлов, восстановление системы, Storage Spaces). Особенности различных версий Windows 8.
курсовая работа , добавлен 25.01.2016
Этапы разработки автоматизированной системы приема и бронирования заказов столиков в заведениях. Анализ среды разработки Android Development Tools. Общая характеристика диаграммы компонентов IOS приложения. Рассмотрение системы контроля версий сервера.
курсовая работа , добавлен 14.05.2014
Графические интерфейсы и расширения для DOS. История развития операционной системы Microsoft Windows. Новшества ее современных версий: пользовательский интерфейс, языковая интеграция, системы защиты. Хронология развития и архитектура системы GNU/Linux.
реферат , добавлен 25.10.2010
Пакет средств разработки DirectX под Microsoft Windows, характеристика наборов COM-совместимых объектов в его составе. Ключевые особенности версий, шейдерные языки. Описание основных используемых функций. Исходный код программы, примеры ее работы.
курсовая работа , добавлен 16.02.2015
Windows как посредник пользователя и операционной системы, облегчая процесс общения между ними, история становления и развития ее первых версий. Функциональные особенности и отличия Windows 95/98/ME и Windows NT/2000/XP/Vista/7, их архитектурные решения.
презентация , добавлен 23.10.2013
Сокращение затрат на ремонтные работы по устранению дефектов, достигаемых при использовании информационной системы для их контроля. Анализ предметной области и программных средств. Расчет экономии за счет увеличения производительности труда пользователя.
дипломная работа , добавлен 19.01.2017
Понятие, сущность, структура и виды операционных систем. Характеристика операционной системы Windows XP, требования к ее установке, сравнительный анализ версий, особенности настройки, обновления версии, установки драйверов устройств и добавление новых.
реферат , добавлен 20.10.2009
Появление первых версий Windows, их графические интерфейсы и расширения для DOS. Семейства Windows 3.x и Windows 9.x, их особенности и основные функции. Эволюция технологии Plug and Play. Наиболее существенные улучшения в современных версиях Windows.
Так как наша команда программистов ведет разработку сразу несколько проектов, довольно быстро возникла необходимость в системе контроля версий.
Естественно, поиски были начаты с изучения Хабра - и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.
Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет:).
Почему мы считаем, что работа с командной строкой неэффективна?
Если вы не любитель мануалов «Для чайников», то можете не читать данную статью и пойти своим путем в решении задачи подъема VCS.
Данный клиент необходимо будет устанавливать на всех компьютерах, с которых будет вестись совместная разработка проектов.
В данной инструкции все шаги настройки и работы с системой контроля версий будут производиться с использованием TortoiseHg версии: 2.10.1 for Windows 64-bit with Mercurial 2.8.1.
2. Регистрируемся в веб-сервисе Bitbucket: https://bitbucket.org/
Весь процесс регистрации сводится к заполнению контактных данных (Username, Email и т.д.) и подтверждения указанного при регистрации email-адреса нажатием на кнопку «Confirm this email address» в полученном после регистрации письме.
Регистрироваться в сервисе Bitbucket потребуется также всем участникам вашей команды разработчиков. К великому счастью стартапов в данном сервисе есть бесплатный аккаунт, который позволяет создавать приватные репозитории с 5-ю пользователями. Также есть возможность увеличения максимального числа членов команды, участвующей в разработке на бесплатном тарифе до 8 человек.
С полным списком тарифов вы можете ознакомиться, пройдя по ссылке: https://bitbucket.org/plans
3. Зайдя в ваш аккаунт в сервисе Bitbucket, вы можете сразу изменить язык интерфейса вашего аккаунта на русский.
Для этого в верхнем правом углу главного меню из выпадающего списка выберите раздел «Manage account» и на открывшейся странице выберите из выпадающего списка «Language» нужный вам язык интерфейса
4. Для создание репозитория для вашего проекта вам необходимо перейдите на главную страницу вашего аккаунта (https://bitbucket.org/dashboard/overview) и нажмите на кнопку «Создайте ваш первый репозиторий»
5. На странице создания нового репозитория укажите следующие настройки:
Имя – Укажите имя вашего нового репозитория. Данное имя используется для построения ссылки доступа к вашему репозиторию.
Важно!
Лучше указывать имя латинскими буквами, иначе ссылка на репозитрий будет заканчиваться дефисами и иметь сложный к пониманию вид: httрs://вашлогин@bitbucket.org/вашлогин/--------
Описание – Укажите краткое описание вашего репозитория (поле не обязательное)
- Уровень доступа – Поставьте галочку, если вы хотите, чтобы доступ к вашему репозиторию имели только члены вашей команды разработчиков (приватный репозиторий).
- Создание форков – Поставьте «Разрешить только приватные форки»
- Тип репозитория – Выберите «Mercurial»
- Управление проектом – Поставьте галочки «Трекер задач» и «Вики»
- Язык – Выберите язык разработки, на котором написан ваш проект. В моем случае это PHP.
По завершению указания всех настроек страница будет выгладить приблизительно так:
Еще раз проверьте введенные данные и если все введено корректно, жмем кнопку «Создать репозиторий».
6. После создания нового репозитория вы попадете на страницу «Начало работы»:
7. У себя на компьютере создаете пустую папку, в которой будут в дальнейшем храниться файлы вашего проекта, подключенные к системе контроля версий Mercurial.
Важно! Папка должна быть пустой. Мне, например, для подключения папки с уже существующим проектом (кучей программного кода) пришлось временно перенести все файлы в другой каталог (сделать резервную копию - backup). Позже мы вернем все файлы на место, а пока нужно полностью очистить папку для подключения.
8. В открывшемся окне вам необходимо указать в поле «Источник» ссылку для подключения к созданному вами репозиторию из п. 6
И нажать кнопку «Клонировать».
9. Система запросит у вас пароль от вашего аккаунта в сервисе Bitbucket, укажите его.
10. Если все было сделано без отклонений от данной инструкции, то в папке появится новый каталог «.hg» со служебными файлами созданного репозитория.
11. Теперь можно смело возвращать файлы (программный код) вашего проекта в папку, предназначенную для хранения файлов проекта, подключенных к системе контроля версий Mercurial
Важно! Служебный каталог «.hg» не трогайте. Он нужен для работы VCS.
12. Снова нажимаем правой кнопкой мыши на нашей папке проекта и из выпадающего меню выбираем пункт «Hg Commit…»
13. Вы увидите диалоговое окно, предназначенное для фиксации всех сделанных изменений, произведенных над вашим проектом (в данном случае мы добавили в изначально пустую папку проекта наши программные коды).
Вам необходимо выделить все измененные (добавленные) файлы, указать комментарий (например, Версия 1.00) к изменению и нажать кнопку «Фиксировать».
Система попросит подтвердить добавление, жмите «Добавить».
14. Если все было сделано правильно, то система зафиксирует произведенные изменения, и вы увидите приблизительно такое окно:
Собственно, в дальнейшем, когда будете вести разработку, после завершения небольшого куска кода, вы будете выполнять действие из п. 12 (нажимать «Hg Commit…») для фиксации проделанного изменения в системе контроля версия. Это даст вам возможность в любой момент времени откатить систему до предыдущей фиксации.
Учитывая вышесказанное, на практике следует писать более развернутый, чем «Версия 1.00», комментарий к каждой из фиксаций.
16. В открывшемся окне вы можете видеть всю историю сохраненных (зафиксированных) изменений в коде, можете откатить к нужной фиксации, а также отправить изменения в созданный вами ранее репозиторий.
Для этого в панели управления выберите кнопку «Протолкнуть входящие изменения в».
После этого вам будут показаны диалоговые окна с просьбой подтвердить «проталкивание» и просьбой указать пароль от вашего аккаунта в Bitbucket. Соглашайтесь и указывайте пароль.
Система начнет копирование файлов в ваш репозиторий на сервере Bitbucket. Не спешите и дождитесь завершения процесса.
17. Теперь копия файлов вашего проекта храниться в вашем репозитории на серверах Bitbucket. В вашем аккаунте Bitbucket вы можете видеть всю историю работы с вашим проектом.
Процесс подключения вашего второго компьютера заключается в копировании файлов из репозитория на второй компьютер. Вам нужно пройти шаги 1 – Установка TortoiseHg и 7 – Импорт файлов репозитория, для копирования файлов на второй, третий и следующие ваши рабочие компьютеры.
Поэтому давайте сейчас подключим к нашему проекту еще одного программиста (пригласим участника) и настроим ему рабочее место.
Как зарегистрироваться на сервисе и установить TortoiseHg, я рассказывал чуть ранее в данной инструкции. Поэтому данный процесс не должен вызвать у вас и ваших коллег никаких трудностей.
19. Зайдите в ваш аккаунт на сервисе Bitbucket:
Нажмите на кнопку «Отправить приглашение», расположенную в разделе «Пригласить участника на этот репозиторий».
20. Система выведет вам диалоговое окно с просьбой указать электронный адрес пользователя, которому вы хотите дать доступ к репозиторию. Помимо этого, вам понадобится указать права доступа («чтение» или «запись»). Т.к. в данной инструкции мы показываем, как подключить к репозиторию еще одного разработчика, то укажите «запись».
После того, как ввели email сотрудника и указали права доступа, жмите кнопку «Share».
21. Приглашенный участник получит на свой email письмо со ссылкой на приглашение. Ему будет необходимо пройти по данной ссылке и принять приглашение на доступ к вашему репозиторию.
Еще раз повторю, все участники вашего репозитория должны быть зарегистрированы в сервисе Bitbucket.
22. После того, как приглашение принято, новый участник будет видеть у себя в аккаунте данный репозиторий и свою ссылку на доступ к нему с помощью TortoiseHg.
Все изменения, сделанные вами и вашими помощниками, будут сохраняться в вашем репозитории. Вы сможете смотреть, что и когда было изменено и при желании в любой момент откатите ваш проект к нужной версии.
Я думаю, вводную статью о развертывании системы контроля версий без использования командной строки можно на этом заканчивать. Прохождение описанных выше шагов позволит вам внедрить у себя на проекте полноценную VCS, т.е. пройдя все шаги, вы получите хоть и не большой, но законченный результат.
Данный подход мы применили для разработки проекта.
Миша Радионов
Представьте себе ситуацию: вы наняли разработчика, чтобы он добавил к вашему интернет-магазину, скажем, функцию быстрого заказа. Так как сайт все время должен функционировать и приносить доход, разработчик решает вести работы на своем локальном сервере.
Пока он работает, дизайнер прислал новый логотип, который вы тут же сами заменили в шаблоне на основной версии сайта. Заодно вы уменьшили шрифт в названиях товаров, чтобы все влезло на экран нетбука одного из ваших клиентов. Потом вы обновили пару картинок для товаров. В это время разработчик решил сделать вам услугу - вычистить в своей версии вашего сайта откровенно ненужный функционал, который писал предыдущий разработчик. Как это часто бывает, вы оба думаете, что ничего серьезного не делали. Но вы ошибаетесь.
Когда версия разработчика заливается на сайт, все участники разработки хватаются за голову. Ваши результаты работы стерты, валятся ошибки. В чем проблема непонятно. Надеюсь, в этот момент у вас хотя бы будет под рукой рабочий бекап, и в худшем случае вы потратите несколько дней на ручной отлов проблем. Как не попасть в такую ситуацию? Рассказываем.
Система управления версиями (от англ. Version Control System, VCS или Revision Control System) - программное обеспечение для облегчения работы с изменяющейся информацией.Wikipedia
Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Другими словами, VCS позволяет изменять одни и те же файлы нескольким разработчикам одновременно и без создания локальных копий на их компьютерах. При этом все варианты изменений сохраняются отдельно, и можно сделать разные варианты одного и того же файла с учетом разных правок от разных людей. Если же несколько изменений затрагивают один и тот же фрагмент документа, то система предложит выбрать нужный вариант.
Обычно для работы с системой контроля версий используется отдельный компьютер (сервер) или интернет-сервис, предоставляющий возможность аренды подобного сервера.
Если над одним Excel документом работает несколько человек, то для редактирования файл доступен только одному человеку, остальные получают доступ “только на чтение”. С использованием VCS Вы получаете возможность редактирования файла сразу и всеми. Единственным условием является только то, что после внесения изменений, файл нужно сохранить на сервер, а не на локальный компьютер. Но как было сказано выше, инструменты позволяют производить такие действия легко и просто.
В нашей работе мы используем систему контроля версий Git. Эта система является одной из самых распространенных VCS. Отсюда вытекает большая поддержка сообществом, использующим Git. Так же плюсом является простое освоение системы, т.к. существует большой спектр программных продуктов разработанных конкретно под эту систему.
Мы используем программу для разработки программного кода, которая называется IntelliJ IDEA . Она предоставляет собой IDE, то есть большую функциональную базу для разработчиков, в том числе в нее включен удобный интерфейс по работе с контролем версий. Так, не выходя из программы, мы можем увидеть, какие изменения были произведены тем или иным разработчиком на нужном нам сайте. Или, не боясь потерять свои изменения, получить изменения, сделанные другим разработчиком. Выглядит интерфейс IDEA примерно так:
Для хранения версий мы пользуемся облачным сервисом Bitbucket . Этот сервис удобен своим интерфейсом и, помимо услуг по хранению ваших версий, позволяет управлять правилами доступа к вашим продуктам разным пользователям. Плюсом использования облачного хранилища является отсутствие каких-то требований к знанию настройки и администрирования сервера. Вы все получаете “из коробки” и сразу можете начинать пользоваться. Все, что вы загружаете в bitbucket, является приватным, т.е. без вашего разрешения никто другой не сможет даже увидеть, что вы храните. Интерфейс Bitbucket:
Вернемся к ситуации, о которой шла речь в начале. Как это было бы с VCS. Разработчик заливает свой код в отдельную ветку. Вы просматриваете изменения и применяете их, только если видите, что все в порядке. Все хранится в одном месте, безопасно, быстро и удобно. А когда разработчиков несколько, без VCS вы вообще не обойдетесь.
Please enable JavaScript to view theРаспределенная система управления версиями Git. Часть 1
Во время работы над проектом его участники часто сталкиваются с проблемами синхронизации и ведения истории файлов, решить которые помогают системы управления версиями (СУВ). Цель этой серии статей – познакомить читателя с принципами работы СУВ и подробно рассмотреть одну из них, а именно Git. Почему Git? В последнее время эта система набирает популярность, и ее важность для свободного ПО (и для проекта GNU/Linux, в частности) сложно переоценить.
Мы последовательно, в общих чертах, разберем характеристики систем контроля, расскажем об их архитектуре и основных особенностях рассматриваемого приложения. Кроме того, сделаем обзор ныне существующих интерфейсов для работы с Git.
Автор сознательно опускает терминологию функций, ключей и прочих тонкостей, чтобы четко, ясно и в общем виде представить вам картину. Данная статья предполагает, что читатель знаком с Unix-подобными операционными системами (ОС), а также имеет базовые знания в области алгоритмики и информатики в целом.
В следующих материалах мы углубимся в структуру и философию Git, специфику этой системы и тонкости практической работы с ней. Завершит цикл статья о взаимодействии Git с другими СУВ (такими как Subversion, CVS, Mercurial и др.).
Git – это распределённая система управления версиями файлов. Код программы написан в основном на языке С. Проект был создан Линусом Торвальдсом в 2005 году для управления разработкой ядра Linux и, как и GNU/Linux, является свободным программным обеспечением (ПО), при этом стороннее использование подчиняется лицензии GNU GPL версии 2. Вкратце данное соглашение можно охарактеризовать как ПО со свободным кодом, которое должно развиваться открыто, т.е. любой программист вправе продолжить совершенствование проекта на любом его этапе. За свое недолгое время существования данная система была введена многими ведущими разработчиками. Git используется в таких известных Linux-сообществу проектах, как Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.
Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией. Разберем общий вид разработки на примере.
Предположим, есть некий проект, который вы разрабатываете, несколько отделов программистов и вы – координатор (или руководитель). По отношению к системе контроля, будь то сервер (если речь идет о централизованной системе) или локальная машина, любой разработчик проекта ограничен только правами доступа на изменение и/или чтение версий файлов данного хранилища. В любой момент вы можете сделать откат данных до необходимой вам версии. Вы, как координатор, можете ограничить доступ определенным пользователям на обновление версии файла. Также СУВ предоставляет интерфейс наблюдения и поиска версий файлов. Например, можно создать запрос: “Где и когда менялся данный кусок кода?”.
Система предполагает защищенное хранение данных, т.е. любой хранимый в ней блок имеет множество клонов. Так, например, при повреждении какого-либо файла вы своевременно можете заменить его копией. Для уменьшения объема данных проекта часто используется дельта-компрессия – такой вид хранения, при котором хранятся не сами версии файла, а только изменения между последовательными ревизиями.
Распределённые системы управления версиями – это СУВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СУВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СУВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта. Рассмотрим эту особенность, продолжая предыдущий пример.
У каждого разработчика на машине есть свой локальный репозиторий – место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СУВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.
Стоит сказать, что система если и не произвела фурор, то немного всколыхнула сообщество в области СУВ своей новизной и предложила новый путь развития. Git предоставляет гибкие и простые в использовании инструменты для ведения истории проекта.
Особенностью Git является то, что работа над версиями проекта может происходить не в хронологическом порядке. Разработка может вестись в нескольких параллельных ветвях, которые могут сливаться и разделяться в любой момент проектирования.
Git – довольно гибкая система, и область её применения ограничивается не только сферой разработки. Например, журналисты, авторы технической литературы, администраторы, преподаватели вузов вполне могут использовать её в своем роде деятельности. К таковым задачам можно отнести контроль версий какой-либо документации, доклада, домашних заданий.
Выделим основные отличия Git от других распределенных и централизованных СУВ.
SHA1 (Secure Hash Algorithm 1) – это алгоритм криптографического хеширования. Каждый файл вашего проекта в Git состоит из имени и содержания. Имя – это первые 20 байтов данных, оно наглядно записывается сорока символами в шестнадцатеричной системе счисления. Данный ключ получается хешированием содержимого файла. Так, например, сравнив два имени, мы можем почти со стопроцентной вероятностью сказать, что они имеют одинаковое содержание. Также, имена идентичных объектов в разных ветвях (репозиториях) – одинаковы, что позволяет напрямую оперировать данными. Хорошим дополнением сказанному выше служит ещё то, что хеш позволяет точно определить поврежденность файлов. Например, сравнив хеш содержимого с именем, мы можем вполне точно сказать, повреждены данные или нет. Далее под именем мы будем понимать имя файла, а строку символов будем называть SHA1-хешем.
Стоит упомянуть о так называемых коллизиях. “Вполне точно определить поврежденность” означает, что существуют такие файлы, различные по содержанию, SHA1-хеш которых совпадает. Вероятность таких коллизий очень мала, и по предварительной оценке равна 2 в -80-й степени (~ 10 в -25-й степени). Точной оценки нет, так как на данный момент мировому сообществу не удалось эффективно расшифровать данную криптографическую схему.
Работу с версиями файлов в Git можно сравнить с обычными операциями над файловой системой. Структура состоит из четырех типов объектов: Blob, Tree, Commit и References; некоторые из них, в свою очередь, делятся на подобъекты.
Blob (Binary Large Object) – тип данных, который вмещает лишь содержимое файла и собственный SHA1-хеш. Blob является основным и единственным носителем данных в структуре Git. Можно провести параллель между данным объектом и инодами (inodes) в файловых системах, поскольку их структура и цели во многом схожи.
Дерево (Tree)
По своей сути объект является аналогом директории. Он задает иерархию файлов проекта.
Commit – тип данных, который содержит:
Данный объект призван хранить снимок (версию) группы файлов в определенный момент времени, можно сравнить его с контрольной точкой. Commit’ы можно объединять (merge), разветвлять (branch) или, например, установить линейную структуру, тем самым отражая иерархию версий проекта.
Reference – тип данных, содержащий ссылку на любой из четырех объектов (Blob, Tree, Commit и References). Основная цель его – прямо или косвенно указывать на объект и являться синонимом файла, на который он ссылается. Тем самым повышается понимание структуры проекта. Очень неудобно оперировать бессмысленным набором символов в названии, ссылку же, в отличие от SHA1-хеша, можно именовать так, как удобнее разработчику.
Из ссылок, в свою очередь, можно выделить ряд подобъектов, имеющих некоторые различия: Ветвь, Тег. Рассмотрим их.
Ветвь (Head, Branch) – символьная ссылка (Symbolic link), которая указывает на последний в хронологии commit определенной ветви и хранит SHA1-хеш объекта. Является типом данных журналируемых файловых систем. Данный вид объекта определяется не в самом Git, а наследуется от операционной и файловой систем. Ветвь используется как синоним файла, на который она ссылается, т.е. Git позволяет оперировать ею напрямую. Можно позволить себе не задумываться о том, работаете ли вы с последней версией или нет.
Тег (tag) – тип данных, который в отличие от ветвей неизменно ссылается на один и тот же объект типа blob, tree, commit или tag. Его, в свою очередь, можно разделить на легковесный (light tag) и тяжеловесный или аннотированный (annotated tag). Легкий тег, кроме неизменности ссылки, ничем не отличается от обычных ветвей, т.е. содержит лишь SHA1-хеш объекта, на который ссылается, внутри себя. Аннотированный тег состоит из двух частей:
Иными словами, проект в Git представляет собой набор blob’ов, которые связаны сетью деревьев. Полученная иерархическая структура может, в зависимости от времени, быть отражена в виде commit’ов – версий, а для понимания их структуры в Git присутствуют такие объекты, как ссылки. Исключая действия со ссылками, почти вся работа с объектами системы максимально автоматизирована изнутри. Отталкиваясь от механизма ссылок, мы приходим к следующей идее – работать именно над группами файлов. По мнению автора, мысль является ключевой в философии Git. Задав, например, операцию для данного commit’а, она рекурсивно отработает свою часть по дереву, на которое ссылается. Являясь расширением общепринятого взгляда “действие над каждым файлом”, нововведение упрощает реализацию и подход со стороны программиста над повседневными задачами СУВ, такими как слияние/разделение ветвей, опять же рекурсивно автоматизируя процесс. Данный подход прост для понимания, быстро работает и гибок в реализации своих целей. Многие из этих черт достигаются благодаря Unix-ориентированности системы, т.е. оперируя стандартными устройствами, Git опирается на уже имеющиеся в операционной системе решения.
Проясним момент хранения данных. Содержание файлов разных версий в хронологии занимает довольно много памяти. Так, например, в проекте из двадцати файлов двадцати версий архив будет весить в 20 раз больше (возможно, порядка сотни мегабайтов), а что будет, если количество и тех и других в 10 раз больше (вроде бы не намного)? Размер занятого пространства возрастет в 100 раз (т.е. примерно 1 ГБ). В реальных задачах скорость роста занимаемой памяти далеко не линейно зависит от времени. Для решения данной проблемы существует несколько оптимизаций:
Разберем на примере.
У вас есть трехлетняя история вашего проекта, в ней порядка тысячи файлов и ста версий. Если в определенный момент нужно будет обратиться к самой ранней версии, Git придется разархивировать дельта-компрессию всей истории файла. Неутешительно, но на данный процесс может уйти до полудня. Git предлагает делать так называемые контрольные точки, т.е. хранить недельта-архивированный файл через некоторое количество версий, которое назовем глубиной компрессии. Тогда в нашем примере вся история сужается до некоторого наперед заданного количества дельта-компрессий, разархивировав которые, можно взглянуть на любую версию в хронологии. Заметим, что дельта-компрессию наиболее целесообразно использовать над одними видами ближайших в иерархии объектов, для этого репозиторий необходимо отсортировать соответственно по типу и размеру. Данный ряд операций, описанных в этом пункте, выполняет функция git-repack (и git-gc, которая её содержит).
Данный вопрос очень трудоемок и насыщен, в связи с чем введем понятия слияния и разделения только в общих чертах. Снова обратимся к примеру.
Представим себе момент разработки проекта, когда главной поставленной целью является скорость работы программы. Один из возможных тактических вариантов решения – разбить разработчиков на две группы, каждая из которых будет решать одну и ту же задачу. При этом ветвь истории проекта должна раздвоиться. Данная процедура называется ветвление (branch). Действие разветвления ветви – это простое создание её копии, которая впоследствии будет иметь свою историю.
Пусть мы получили два уже законченных результата одной и той же задачи, над которой работали две группы программистов. Как нам быть? Посмотреть, чей код быстрее и надежнее? Это слишком просто, но не всегда лучший выход. Хорошее решение – это, немного разобравшись в коде и файлах, разбить их на подзадачи или блоки кода. И только тогда уже выявлять сильные и слабые стороны данных кусочков. Конечно, этот вариант подходит только в том случае, когда вы заранее предусмотрели, что впоследствии сможете собрать все эти частицы воедино. Случай, когда вы сами разрабатываете код, улучшая и исправляя некоторые ошибки, равнозначен приведенному примеру. Данный процесс объединения двух целых в одно называется слияние (merge). Процесс объединения двух версий и есть ключевой момент ведения проекта. Как бы то ни было, стоит избегать автоматизированного исполнения данной операции. Отличительная черта Git – это максимально достоверный и довольно быстрый способ решения задачи ветвления.
К достоинствам системы можно отнести:
К недостаткам отнесем:
«Сколько людей, столько и мнений». Попробуем выделить ряд типов интерфейсов для работы с системой. Для определенных целей по-своему лучше каждое из приведеных ниже видов приложений.
Для людей, которые не занимаются разработкой вплотную, для «консерваторов» – тех, кто любит “кнопочки и галочки” и сознательно хочет оградить себя от непомерных усилий запоминания функций, ключей и многих тонкостей, больше подойдет вариант в стиле TortoiseGit или Git Extensions – простые интерфейсы. Они позволяют действовать преимущественно мышью и работают в привычной для многих ОС Windows.
Ровно противоположный тип интерфейса. Для программистов, которым постоянно необходимо взаимодействовать с сотрудниками, решать типичные задачи контроля именно кода, для людей, которые привыкли работать в Unix-like системах, используя терминал, лучше всего подойдет консольный вид приложений. Они так же просты в обращении, немного быстрее и функциональнее, но им придется уделить время, для того чтобы разобраться в использовании.
Можно выделить и третий тип интерфейсов – смешение первых двух. Т.е. у вас есть консольное приложение, например, “родная” оболочка git. Вы можете использовать ряд дополнительных утилит, таких как Gitk или QGit, для отображения деревьев, упрощения обзора иерархии версий, различий между версиями, поиска нужных объектов.