Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
1.doc
Скачиваний:
118
Добавлен:
20.04.2015
Размер:
191.49 Кб
Скачать

Лабораторная работа №1. Локальный Git.

Цель лабораторной: получить понимание необходимости инструментов контроля версий (VCS — version control system), изучить основы локальной работы с VCS Git.

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

Для чего вообще нужны инструменты управления исходным кодом продукта? А в общем случае и для управления произвольными исходными частями продукта (здесь можно упомянуть, например, файлы стилей CSS, любые конфигурационные файлы и т.д.)? На этот вопрос и отвечает параграф, который вы читаете. Обращайте внимание на выделенные слова, они обозначают базовые операции и позволят вам видеть логику названий команд.

Начнём с самого простого и очевидного — хранение истории изменений. Это нужно затем, чтобы знать автора изменений (user)проекта, получитьстарую версию (tag, branch)продукта, которая, кстати, может быть стабильней текущей, отслеживать активность участников проекта, их продуктивность и качество работы. Обычно это решается просто с помощью создания резервных копий. Однако они несут мало информации о процессе разработки, об авторах изменений и, как правило, делаются в определённый момент времени, который может не совпадать смоментом изменения (commit)в проекте. К тому же сложноотслеживать изменения (log), ведь нужно вручную сравнивать папки каким-нибудь инстументом сравнения (например, Meld).

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

Инструменты контроля версий призваны решать задачу объединения работы (merge)авторов, которые выполняют её на физически разных машинах, что крайне затруднительно (скорее даже невозможно) в случае использования резервных копий. Также системы контроля версий позволяютлегко создавать новые экспериментальные версии (branch, stash), сохраняя при этом стабильные старые. Это позволяет легко экспериментировать с изменениями, вливая в стабильную версию часть экспериментальных, отменяя все нестабильные изменения и многое другое.

Когда вы ознакомились с базовыми возможностями, которые должна предоставлять любая система контроля версий, а также с проблемами резервного копирования, можно приступить к ознакомлению с уже существующими продуктами в данной области. Здесь также нет единого подхода: инструменты разделяются на централизованные и распределённые системы контроля. К первым относится популярный продукт SVN (Subversion). Централизованные системы имеют сравнительно низкую отказоустойчивость, т.к. всё хранится сосредоточенно в одном месте и аппаратный сбой системы приведёт к потере всей истории изменений. Принципиально другой подход реализуется в распределённых системах контроля, таких как Git. Они предполагают хранение всей истории изменений на компьютере каждого автора. Это делает систему максимально устойчивой к сбоям, однако, затрудняет распространение изменений в истории. В данной лабораторной работе будет рассмотрена именно VCS Git, т.к. она сейчас набирает популярность, а также предлагает широкий набор возможностей для работы с историей версий.

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

Для того, чтобы начать работу с Git необходимо установить его пакет к себе на компьютер. В случае с Linux это делается просто путём установки пакета git, который доступен в репозиториях (аналогичное приведённому ранее понитие) пакетов. Для Windows нужно установить специальную сборку msysgit (http://code.google.com/p/msysgit/). Помимо Git она установит Cygwin, который необходим для работы в Git из-под Windows.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]