Управление исходным кодом с помощью GIT

Размещено на http://www.allbest.ru/

Министерство Образования Республики Молдова

Технический Университет Молдовы

Факультет CIM

Кафедра ATI

Отчет

по лабораторной работе №1

по дисциплине: PR

Тема: «Управление исходным кодом с помощью GIT»

Подготовил: студент гр. TI-125

Якимов. А

Проверил: старший преподаватель каф. ATI

Чёрба Д.

Кишинев - 2015

Цель работы: Создание удаленного хранилища, расположенного на gitlab.ati.utm.md, а также синхронизация всех изменений, внесенных в локальный репозиторий.

1. Теоретическая часть

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

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

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

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

В отличие от других систем контроля версий, Git не хранит изменения файлов от их начального состояния к какому-либо состоянию на момент фиксации изменений, пример на Рис 1.[1]

Рис.1 VCS, хранящие изменения файлов [1]

Вместо этого Git всегда хранит всё состояние проекта в виде фиксаций (commits, разг. комитов), которые представляют собой снимок (snapshot) директории именно в тот момент, когда разработчик решил внести изменение. Стоит отметить, что момент внесения изменений и их фиксации, конечно, отличается. Git настолько мощный, что позволяет фиксировать только части внесённых изменений. Тут можно заметить одну сложность: если Git каждый раз создаёт фиксацию всех файлов целиком, то как он хранит неизменённые при фиксации файлы? Решение этого вопроса было простым и гениальным: Git хранит ссылку на ранее фиксированный файл. Это ведёт к полному пересмотрению обычного процесса разработки и даёт Git его популярную возможность легко работать с нелинейными проектами, развитие отдельных частей котоых идёт параллельно. Это всё можно увидеть на Рис 2. [1]

Рис 2 Устройство Git[1]

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

Немаловажной является и возможность локальной работы. Это позволяет выполнять работу где угодно, и когда угодно. Как правило, этот плюс Git ставится в противоположность CVCS, в которых локальная работа крайне затруднительна. Более того, вы можете даже забросить ваши изменения, затем вернуться к ним, обновить историю, предшествующую им, и всё равно нормально влить свои изменения в проект. Так как Git был разработан для управления большими проектами, такими как ядро Linux, то он также предполагает множество процессов разработки, позволяя, например, пересылать свои изменения по электронной почте или упаковать их в один файл, который можно передать, используя USB-носитель. Отдельно стоит заметить, что “центральный” репозиторий в Git всё же существует. Однако он никогда не употребляется в буквальном значении и обычно пишется в кавычках. Он используется для того, чтобы разработчики могли публиковать свои изменения и обмениваться актуальным состоянием проекта. Git и данные Git сохраняет все данные, используя для при их хранении контрольную сумму SHA-1, вычисленную на основе файла или каталога. Длинна данного хэша составляет 40 символов. Он используется Git в качестве индекса при обращении к файлам в своей базе данных. Также эта контрольная сумма позволяет Git удостовериться в том, что данные были изменены или не были повреждены при передаче, ведь в таком случае контрольная сумма будет другой. Три состояния файла в Git В Git файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. «Зафиксированный» значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы -- это изменённые файлы, отмеченные для включения в следующий коммит. Таким образом, в проекте с использованием Git есть три части: каталог Git (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).[1]

Каталог Git -- это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git. Рабочий каталог -- это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git и помещаются на диск для того, чтобы вы их просматривали и редактировали. Область подготовленных файлов -- это обычный файл, обычно хранящийся в каталоге Git, который содержит информацию о том, что должно войти в следующий коммит. На Рис 3 мы можем видеть как происходит коммуникация между тремя основными частями Git.[1]

Рис 3. Рабочий каталог, область подготовленных файлов, каталог Git.[1]

Стандартный рабочий процесс с использованием Git выглядит примерно так, как изображено выше на рисунке. Вы изменяете файлы в вашем рабочем каталоге. Вы подготавливаете файлы, добавляя их слепки в область подготовленных файлов. Вы делаете коммит. При этом слепки из области подготовленных файлов сохраняются в каталог Git. Если рабочая версия файла совпадает с версией в каталоге Git, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым.[1]

Git поддерживают несколько крупных репозиториев -- GitHub, SourceForge, BitBucket и Google Code пример на Рис 4.[1] Удобно использовать один из них в качестве основного хранилища для корпоративных проектов, но для своей лабораторной работы мы будем использовать репозиторий под название GitLab. (https://gitlab.ati.utm.md)

Рис 4. Виды репозиториев.[1]

Основные команды Git, необходимые для работы с данным механизмом:

· git init - новый репозиторий;

· git status - состояние: что было редактировано, что добавлено в индекс для коммита;

· git add. - добавить в индекс все изменения;

· git add file.txt - добавить содержимое файла в индекс;

· git add -i - интерактивное добавление позволяет выбирать файлы, которые надо добавить. Для каждого файла можно добавить некоторые изменения, другие оставить для следующего коммита.;

· git commit -m "initial commit" - первый commit (некоторые команды криво работают, пока не сделать первый коммит);

· git commit -am "comment" - add + commit, но новые файлы не будут добавлены;

· git commit --amend - докоммитить предыдущий коммит. если что еще надо в него добавить или изменить текст коммита;

· git commit --amend -m "new comment";

· git branch - список веток;

· git branch newfeature - создать ветку newfeature;

· git checkout newfeature -- выбор ветки;

· git commit -am "new feature done" - ее commit;

· git checkout master - переход в ветку master;

· git merge newfeature - объединение ветки newfeature с master;

· git reset --soft <commit> - делает <commit> последним коммитом (HEAD'ом).;

· git stash - сделать временный коммит рабочей папки;

· git stash apply - вернуть рабочую папку обратно;

· git status list - выводит список стешей, их может быть много, например;

· git stash save "comment";

· git stash apply stash@{1} - где stash@{1} - нужный стеш из git status list;

· git rebase master - на master накладывается текущая ветка (сначала будут идти все коммиты master, потом все коммиты текущей ветки). Если просто объединить, то коммиты будут перемешаны и получится не красиво;

· если возникли конфликты, их надо разрешить и запустить ;

· git push origin master - пихает изменения из текущей ветки в origin master. Желательно делать push только в bare репозитории, т.к. команда push портит содержимое рабочей папки;

· git pull origin master - берёт изменения из репозитория на локальный репозиторий.[2]

2. Ход работы

1. Устанавливаем систему контроля версий. Для этого скачиваем Git по ссылке http://git-scm.com/downloads

2. Создаем аккаунт на gitlab.ati.utm.md. Затем генерируем ssh-ключ и добавляем его в профиль пользователя в Настройках профиля Рис.5.

Рис 5.Создание SHH ключа

3. Переходим в необходимую директорию и создаем репозиторий Git в этой директории, используя команду git init Рис.6.

Рис 6.Создание репозитория

4.Добавляем в содержимое директории несколько файлов Рис.7.

Рис 7.Создание двух файлов в локальном репозиотрии.

5.Вносим изменения в репозиторий каждый раз, когда были изменены файлы. Рис 8.

Рис 8.Добавление файлов.

6. Обновляем удалённый репозиторий с помощью команды git push -u Рис. 9

Рис 9. Обновление репозитория

7. Проверяем состояние, используя команду git status. Рис. 10.

Рис 10. Команда git status

8. Создаем новую ветку dev и перемещаемся на нее. Можно заметить, что название ветки поменялось Рис. 11

Рис 11. Создание ветки dev

9. Добавляем ветку dev в удаленный репозиторий и проверяем наличие изменений Рис.12.

Рис 12. Добавление ветки dev в удалённый репозиторий

10. При создании ветки dev переноси из ветки master два файла которые находятся в ней, а затем создаём в локальном репозитории файл code3.txt и всё это заносим в удалённый репозиторий в ветку dev Рис. 13.

Рис 13. Добавление файлов в ветку dev

11. Объединяем ветку master с веткой dev Рис 14

Рис 14. Слияние веток dev и master

12. Добавляем изменения в удаленный репозиторий Рис 15.

Рис 15. Добавление в удалённый репозиторий.

Результат проведённой работы можно видеть на Рис.16. Иcходя из содержания рисунка мы можем видеть что файл code3.txt был получен из ветки dev.

Рис 16. Результат работы(содержание ветки master).

Выводы

В процессе проведения данной лабораторной работы, мы получили как практические так и теоретические знания о том, что такое система контроля версий, а так же для чего она нужна, её преимущества и недостатки. В данной лабораторной работе в качестве системы контроля версий мы использовали GIT. Мы узнали принцип работы Git и особенности работы данной системы. Данная система контроля версий является одной из самых популярных из-за большого количества плюсов, которые были рассмотрены в лабораторной работе. Так же в ходе работы мы рассмотрел основные команды Git которые использовались для создания нового репозитория, а так же для добавления файлов на локальный и удалённый репозиторий. В ходе работы мы создали несколько файлов, закинув их на удалённый репозиторий, затем создав дополнительную ветку пользуясь командами Git мы соединил вместе две ветки одну которую мы создали и вторую которая была создана по умолчанию. В данной лабораторной работе мы использовали не все команды Git, но этого было достаточно для того что бы понять как и для чего используется Git. И в результате мы понял, что Git является незаменимым инструментом в сфере ИТ.

хранилище локальный репозиторий файл

Список литературы

1. Scott Chacon and Ben Straub. Pro Git book. Apress, 2009.

2. URL: https://ru.wikipedia.org/wiki/Система_управления_версиями

Размещено на Allbest.ru