НТП_МУ_ЛР. Томский государственный университет систем управления и радиоэлектроники кафедра компьютерных систем в управлении
 Скачать 1.31 Mb.
|
|
3.1.10 Три состояния Теперь внимание. Это самое важное, что нужно помнить про Git, ес- ли вы хотите, чтобы дальше изучение шло гладко. В Git файлы могут на- ходиться в одном из трёх состояний: зафиксированном, изменённом и под- готовленном. «Зафиксированный» значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит. Таким образом, в проекте с использованием Git есть три части: ката- лог Git (Git directory), рабочий каталог (working directory) и область подго- товленных файлов (staging area). Каталог Git — это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git, и именно она ко- пируется, когда вы клонируете репозиторий с другого компьютера. Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге 41 Git и помещаются на диск для того, чтобы вы их просматривали и редак- тировали. Область подготовленных файлов — это обычный файл, обычно хра- нящийся в каталоге Git, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготов- ленных файлов (staging area). Стандартный рабочий процесс с использованием Git выглядит при- мерно так: 1. Вы изменяете файлы в вашем рабочем каталоге. 2. Вы подготавливаете файлы, добавляя их слепки в область подго- товленных файлов. 3. Вы делаете коммит. При этом слепки из области подготовленных файлов сохраняются в каталог Git. Если рабочая версия файла совпадает с версией в каталоге Git, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым. 3.2 Сервис Github GitHub — это один из крупнейших веб-сервисов для хостинга IT-проектов и их совместной разработки. Сервис основан на системе кон- троля версий Git. Сервис бесплатен для проектов с открытым исходным кодом и пре- доставляет им все возможности (включая SSL), а для частных проектов предлагаются различные платные тарифные планы. Для работы с сервисом необходимо зарегистрироваться, зайдя на [2]. После регистрации — заведите репозиторий (зайдите во вкладку Reposito- ries и нажмите на New). При заведении нового репозитория нужно опреде- 42 литься, для чего он нужен, для публичных проектов или для личного за- крытого использования, в зависимости от этого нужно выбрать Public или Private. При создании Private репозитория необходимо будет заплатить по тарифу 7$ в месяц (стоимость на 14.12.2014). Введите имя репозитория и его описание и нажмите на зелёную кнопку Create repository. После создания репозитория будет доступна возможность его клони- рования (физического переноса файлов репозитория на локальную машину для дальнейшей работы или переноса репозитория на другой сервис кон- троля версий, поддерживающий Git). Клонирование возможно по двум протоколам: HTTPS и SSH. Работа по HTTPS достаточно проста и будет рассмотрена ниже. Работа по SSH-протоколу подразумевает наличия SSH- ключей — публичного и приватного. Генерация и работа с последними не представляет никакой особой сложности, выполняется она, например, с помощью утилиты PUTTYgen. В данном пособии эти вопросы рассматри- ваться не будут, поэтому читатель может ознакомиться с генерацией и ис- пользованием ключей самостоятельно. GitHub предоставляет большое количество сопутствующих сервисов для разработки, например отслеживание коммитов, просмотр различий между версиями файлов напрямую в браузере (при этом сервис поддержи- вает синтаксическую подсветку для большинства существующих языков программирования), использование сервиса в качестве системы управле- ния проектами с возможностью создания задач, их отслеживания и т. п., создание документации на основе Wiki, отслеживание активности по про- екту с помощью графиков и пр. Создатели GitHub называют свой проект «социальной сетью для раз- работчиков». Кроме размещения кода, участники могут общаться, коммен- тировать правки друг друга, а также следить за новостями знакомых. Рабо- тая с системами, подобными GitHub, начинающий программист развивает навыки изучения чужого кода и его критической оценки. Очень часто на 43 ресурсе можно найти код именитых разработчиков, изучение которого бу- дет приучать к правильным стандартам и приёмам кодирования. Помимо этого, достаточно опытный разработчик может поучаствовать в интере- сующем Open Source проекте, опять же развивая определённые профес- сиональные компетенции. Сегодня очень часто при приёме на работу продвинутый работода- тель, вместо выдачи тестового задания просит ссылку на публичный репо- зиторий на GitHub и делает вывод по находящимся там проектам о качест- вах кандидата-программиста. Поэтому освоение Git, как одной из СУВ и GitHub, как публичного хранилища репозиториев — позволит студенту иметь определённые навыки для дальнейшей работы разработчиком. GitHub позволяет работать по системе ветвлений напрямую на ре- сурсе, но в методическом пособии будет расмотрена локальная система ветвлений. Применительно к лабораторным работам: использование GitHub или любого другого публичного веб-сервиса для хранения Git-репозитория по- зволит преподавателю оценить работу студента с репозиторием. 3.3 Инструменты работы с Git Для работы с Git репозиториями существует множество инструмен- тов, выбор которых зависит от нескольких факторов: используемой опера- ционной системы и привычного варианта использования программ (с по- мощью пользовательского интерфейса: Mac и Windows стиль или с помо- щью консоли — *nix системы). В данном разделе будут рассмотрены ин- струменты для работы с Git под Windows. 3.3.1 Работа с помощью командной строки Для работы с помощью командной строки необходимо установить Git клиент, предварительно скачав его с [3]. После установки появится 44 возможность использовать команды для настройки Git с помощью ко- мандной строки. Для запуска командной строки запустите Git Bash из меню Пуск или sh.exe, расположенного по пути C:\Program Files (x86)\Git\bin\. Для созда- ния Git-репозитория перейдите в папку, в которой вы хотите создать репо- зиторий, и введите следующую команду: $ git init Создав репозиторий в папке — добавьте в неё некоторые файлы (на- пример, файл README.txt). Для добавления этого файла под версионный контроль — наберите команду: $ git add README.txt или $ git add *.txt Для выполнения своего первого коммита наберите команду: $ git commit –m ‘Первый коммит проекта’ Флаг –m описывает сообщение, которое будет содержать коммит. Если вы желаете получить копию существующего репозитория Git, например проекта, в котором вы хотите поучаствовать, то вам нужна ко- манда $ git clone. Каждая такая команда забирает с сервера копию практи- чески всех данных, что есть на сервере. Фактически, если серверный диск выйдет из строя, вы можете использовать любой из клонов на любом из клиентов для того, чтобы вернуть сервер в то состояние, в котором он на- ходился в момент клонирования. Для клонирования репозитория нужно набрать команду: $ git clone [url] Сейчас измените файл README.txt. После этого можно проверить статус имеющихся файлов командой: $ git status 45 После выполнения команды вы увидите, что файл README.txt из- менился. Для того чтобы выполнить коммит, снова выполните команду коммита, только с флагом –a: $ git commit –a –m ‘Второй коммит проекта’ Флаг –a позволит выполнить коммит модифицированных файлов без необходимости добавления их командой $ git add. Очень часто необходимо иметь возможность автоматического игнори- рования одного или группы файлов. При этом эти файлы хотелось бы видеть в списке отслеживаемых. Для этого вы можете создать файл .gitignore с пере- числением шаблонов, соответствующих таким файлам. Такие файлы можно написать вручную либо можно найти в интернете для интересующего вас ти- па проекта. Для C# .NET проекта файл можно скачать тут [4]. Для того чтобы удалить файл из Git, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса), а затем выполнить коммит. Это позволяет сделать команда $ git rm, которая также удаляет файл из вашего рабочего каталога, так что вы в следующий раз не увидите его как «не отслеживаемый». Другая полезная команда, которую можно выполнить, — это удалить файл из индекса, оставив его при этом в вашем рабочем каталоге. Другими словами, вы можете захотеть оставить файл на жёстком диске и убрать его из-под бдительного ока Git. Для этого выполните команду: $ git rm –cached README.txt Если вам будет необходимо просмотреть историю коммитов — на- берите: $ git log После выполнения команды будет выведен список коммитов, создан- ных в данном репозитории в обратном хронологическом порядке. Эта ко- манда отображает каждый коммит вместе с его контрольной суммой SHA-1, именем и электронной почтой автора, датой создания и комментарием. 46 Существует великое множество параметров команды git log и их ком- бинаций, для того чтобы показать вам именно то, что вы ищите. С пара- метрами команды предлагается разобраться самостоятельно. -p -2 — показ дельты между коммитами для последних двух записей; --stat — показ краткой статистики по каждому коммиту; --pretty= --pretty=format: "%h - %an, %ar : %s" — команда для создания соб- ственного формата вывода лога, которая может быть полезна, когда вы создаёте отчёты для автоматического разбора (парсинга); --since и –until =2.weeks — команда для ограничения вывода по вре- мени, может быть за последние несколько дней, недель, месяцев, а также часов, минут, секунд и пр. На любой стадии может возникнуть необходимость что-либо отме- нить. Будьте осторожны, ибо не всегда можно отменить сами отмены. Это одно из немногих мест в Git, где вы можете потерять свою работу, если сделаете что-то неправильно. Изучите работу с командой $ git commit --amend самостоятельно. Git поддерживает большое количество команд, поэтому при возник- новении вопросов — обязательно обращайтесь к рабочей документации, набрав команду $ git help или для открытия html файла с помощью $ git help git Помимо этого, можно получить помощь на конкретную команду набрав: $ git help Работа с ветками будет рассмотрена в следующем разделе, т.к. её наиболее удобно показать на программе, имеющей пользовательский ин- 47 терфейс. Желающие разобраться с процессом работы с ветками с помощью командной строки могут воспользоваться информацией из Интернета. 3.3.2 Работа с помощью SourceTree (GUI) Для удобства работы с СУВ создаются специальные программы. Данный раздел указаний по лабораторным работам посвящён утилите SourceTree. Выбор пал именно на эту программу, т.к. она бесплатна и, с точки зрения авторов, наиболее удобна из исследованных. Скачать её можно по ссылке [5]. Перечень других GUI-клиентов для Git можно по- смотреть по ссылке [6]. После установки SourceTree и запуска программы будет показано окно, как на рис. 3.6. Рисунок 3.6 — Пользовательский интерфейс SourceTree Если ОС использует русский язык по умолчанию, то и программа будет на русском. Следует отметить некачественный перевод программы, поэтому для соблюдения идентичности кнопок на пользовательском ин- 48 терфейсе с командами консоли работа в дальнейшем будет рассматривать- ся на англоязычной версии интерфейса. Для клонирования имеющегося репозитория с GitHub необходимо нажать на кнопку Clone. После этого появится форма как на рис. 3.7. Рисунок 3.7 — Форма клонирования Git-репозитория Для клонирования репозитория необходимо будет указать путь до него в поле Source Path/URL: и локальное расположение репозитория на ПК в поле Destination Path. Путь репозитория можно взять из GitHub в настройках созданного репозитория (см. рис. 3.8). Рисунок 3.8 — Ссылка на репозиторий в пользовательском интерфейсе SourceTree 49 Помимо этого, GitHub поддерживает обращение к репозиторию не только как к *.git, но и по URL (см. рис. 3.9). Рисунок 3.9 — Форма клонирования Git-репозитория со ссылкой Нажав на кнопку Clone, вы создадите локальную копию всех файлов, хранящихся у вас в репозитории. Добавьте туда файл README.txt. Перейдя в SourceTree, вы увидите, что файл появился в окне программы как не добавленный под версионный контроль (см. рис. 3.10). Рисунок 3.10 — Форма с файлом, не находящимся под версионным контролем Для добавления файла необходимо выделить его галочкой и нажать на кнопку Commit. После этого появится окно для ввода сообщения о ком- мите. Отнеситесь к этому шагу ответственно, так как очень часто разра- 50 ботчики не любят писать много комментариев к коммиту, что приводит к неразберихе при необходимости отката к определённой версии. Это про- исходит, потому что из тысяч коммитов сложно идентифицировать нуж- ный из-за отсутствия необходимой информации. Автоматически ваш коммит будет помещён в ветку master (см. рис. 3.11). Рисунок 3.11 — Первый коммит в SourceTree При необходимости получить/залить изменения из/на GitHub нажми- те кнопку Pull/Push (см. рис. 3.12). Рисунок 3.12 — Рабочая панель SourceTree Измените файл README.txt. После этого в SourceTree появится пре- дупреждение, что у вас есть не добавленные в коммит изменения (см. рис. 3.13). 51 Рисунок 3.13 — Показ не добавленных в коммит изменений в SourceTree Перейдя на выделенный пункт, вы увидите, какие именно файлы бы- ли изменены, а в правом окне вы увидите, что именно было изменено в файле (см. рис. 3.14). Рисунок 3.14 — Отображение изменённых файлов в SourceTree Сделайте коммит изменения. Далее рассмотрим работу с ветками. Наиболее удачная модель работы с ветками представлена в следующей главе, в этой же будет рассмотрен процесс создания веток и их слияния. Для создания ветки нажмите кнопку Branch (см. рис. 3.15). Рисунок 3.15 — Рабочая панель SourceTree 52 Введите имя ветки (см. рис. 3.16). Рисунок 3.16 — Диалог создания ветки в SourceTree Следует заметить, что ветки можно создавать как от последнего коммита, так и от любого другого. После создания ветки она будет отме- чена галочкой как текущая, что значит, что изменения файлов в локальном репозитории будут отражаться именно на текущей ветке (см. рис. 3.17). Рисунок 3.17 — Созданная ветка в SourceTree Поменяйте файл README.txt несколько раз и выполните коммит после каждого изменения (см. рис. 3.18). 53 Рисунок 3.18 — SourceTree после нескольких коммитов Теперь попробуйте перейти на ветку master. Вы увидите, что Git вос- становил версию с содержимым, которое было последним добавлено в ветку. После того, как вы вернулись в master, необходимо выполнить слияние. Запомните, слияние выполняется из ветки, в которую вы хотите выполнить слияние! Для слияния выбираем кнопку Merge (см. рис. 3.19). Рисунок 3.19 — Рабочая панель SourceTree В окне Merge выбираем последний коммит в ветке Development. Всё, вы выполнили слияние двух веток (см. рис. 3.20). Рисунок 3.20 — Выполнение слияния с веткой Development 54 Для того чтобы увидеть систему ветвления вашего проекта в Source- Tree (см. рис. 3.21), необходимо до выполнения слияния с основной веткой выставить настройки (Tools->Options->Git), показанные на рис. 3.22. Рисунок 3.21 — Отображение системы ветвления, после слияния с веткой Development Рисунок 3.22 — Настройки SourceTree для показа системы ветвления проекта 55 После этого можно удалить ветку Development. Это можно сделать, например, наведя мышкой на ветку и выбрав Delete Development в контек- стном меню (см. рис. 3.23). Рисунок 3.23 — Удаление ветки Development Можно увидеть, что ветка Development была успешно удалена. Сде- лав ещё один коммит, можно увидеть, что кнопка Push показывает количе- ство произведённых изменений для отправки в репозиторий, от которого вы создали свой в самом начале (см. рис. 3.24). Рисунок 3.24 — Отображение изменений для отправки в изначальный репозиторий 56 3.4 Удачная модель ветвления для Git Для того чтобы не увеличивать без необходимости пособие, студенту предлагается ознакомиться с удачной моделью ветвления для Git само- стоятельно. Оригинальная статья на английском находится по адресу [7], хоро- ший русский перевод находится тут [8]. Понимание этой модели ветвления должно сформировать у студента понимание организации достаточно удобного процесса командной разра- ботки с помощью Git. Такая модель наиболее хорошо описывает работу над реальным продуктом в динамике. Показанные концепции стройно ло- жатся на модель ветвления Git, позволяя наиболее удобно вносить измене- ния в существующую функциональность продукта, отрабатывать возни- кающие в процессе работы ошибки, а также параллельно работать над но- выми функциями. 3.5 Задание на лабораторную работу 1. Зарегистрируйтесь на GitHub.com. 2. Создайте публичный репозиторий для своего проекта. 3. Установите на своей машине Git клиент. 4. Склонируйте репозиторий на свою машину. 5. Добавьте в склонированный репозиторий ваш проект, над которым вы работали в лабораторных 1 и 2. 6. Сделайте ветку Development и перейдите в неё. 7. Выполните несколько изменений файлов (такими изменениями может быть улучшение читаемости кода, добавление комментариев и пр.). После каждого атомарного изменения выполняйте коммит в репозиторий. К каждому коммиту добавьте осмысленный комментарий, чтобы при не- обходимости можно было опознать, какие были выполнены изменения. 8. После выполнения некоторых изменений слейте ветку Develop- ment и главную ветку master. 57 9. Отправьте изменения на GitHub.com. 10. Всю дальнейшую работу с лабораторными заданиями выполняй- те при параллельном использовании версионного контроля. Любое изме- нение логически должно быть зафиксировано — делайте коммиты в репо- зиторий. При необходимости проведения определённых улучшений про- граммы — создавайте дополнительные ветки, над которыми в дальнейшем выполняйте слияние с главной веткой и фиксируйте промежуточные вари- анты в GitHub.com. |