Эксперт

Сергей

Задать вопрос

Мы готовы помочь Вам.

3.1.2 Централизованные системы управления версиями
Следующей большой проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы управления версиями (ЦСУВ). В
таких системах, например CVS, Subversion и Perforce, есть центральный
сервер, на котором хранятся все отслеживаемые файлы, и ряд клиентов,
которые получают копии файлов из него. Много лет это был стандарт
управления версиями (см. рис. 3.2).
Рисунок 3.2 — Схема централизованной СУВ
Такой подход имеет множество преимуществ, особенно над локальными СУВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСУВ гораздо легче, чем локальные базы на каждом клиенте.
Однако при таком подходе есть и несколько серьёзных недостатков.
Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать и никто не может сохранить новые
версии. Если же повреждается диск с центральной базой данных и нет ре-
35
зервной копии, вы теряете абсолютно всё — всю историю проекта, разве
что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные системы управления версиями
подвержены той же проблеме: если вся история проекта хранится в одном
месте, вы рискуете потерять всё.
3.1.3 Распределённые системы контроля версий
В такой ситуации применяют распределенные системы управления
версиями (РСУВ). В таких системах, как Git, Mercurial, Bazaar или Darcs,
клиенты не просто забирают последние версии файлов, а полностью копируют репозиторий. Поэтому в случае, когда по той или иной причине отключается сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу
данных. Каждый раз, когда клиент забирает свежую версию файлов, создаётся полная копия всех данных (см. рис. 3.3).
Рисунок 3.3 — Схема распределённой СУВ
36
Кроме того, в большей части этих систем можно работать с несколькими удаленными репозиториями, таким образом, можно одновременно
работать по-разному с разными группами людей в рамках одного проекта.
Так, в одном проекте можно одновременно вести несколько типов рабочих
процессов, что невозможно в централизованных системах.
3.1.4 Краткий экскурс в историю появления Git
История Git тесно связана с историей Linux. Ядро Linux — действительно очень большой открытый проект. Большую часть существования
ядра Linux (1991—2002) изменения вносились в код путем приёма патчей
и архивирования версий. В 2002 году проект перешёл на проприетарную
РСУВ Bit-Keeper.
В 2005 году отношения между сообществом разработчиков ядра
Linux и компанией, разрабатывавшей BitKeeper, испортились, и право бесплатного пользования продуктом было отменено. Это подтолкнуло разработчиков Linux (и в частности Линуса Торвальдса, создателя Linux) разработать собственную систему, основываясь на опыте, полученном за время
использования BitKeeper. Основные требования к новой системе были следующими:
• скорость;
• простота дизайна;
• поддержка нелинейной разработки (тысячи параллельных веток);
• полная распределенность;
• возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных).
С момента рождения в 2005 г. Git разрабатывали так, чтобы он был
простым в использовании, сохранив свои первоначальные свойства. Он
невероятно быстр, очень эффективен для больших проектов, а также обладает превосходной системой ветвления для нелинейной разработки.
37
3.1.5 Особенности Git
Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймете, что такое Git и каковы принципы его работы,
вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СУВ, таких как
Subversion или Perforce. В Git совсем не такие понятия об информации и
работе с ней, как в других системах, хотя пользовательский интерфейс
очень похож. Знание этих различий защитит вас от путаницы при использовании Git.
3.1.6 Слепки вместо патчей
Главное отличие Git от любых других СУВ (например, Subversion и
ей подобных) — это то, как Git смотрит на данные. В принципе, большинство других систем хранит информацию как список изменений (патчей)
для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных
для каждого из этих файлов во времени, как показано на рис. 3.4.
Рисунок 3.4 — Схема представления данных в других СУВ
Git не хранит свои данные в таком виде. Вместо этого Git считает
хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент.
38
Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а
делает ссылку на ранее сохранённый файл. То, как Git подходит к хранению данных, похоже на рис. 3.5.
Рисунок 3.5 — Схема представления данных в Git
Это важное отличие Git от практически всех других систем управления версиями. Из-за него Git вынужден пересмотреть практически все аспекты управления версиями, которые другие системы взяли от своих
предшественниц. Git больше похож на небольшую файловую систему с
невероятно мощными инструментами, работающими поверх неё, чем на
просто СУВ. В главе 3, коснувшись работы с ветвями в Git, мы узнаем, какие преимущества даёт такое понимание данных.
3.1.7 Почти все операции — локальные
Для совершения большинства операций в Git необходимы только локальные файлы и ресурсы, т. е. обычно информация с других компьютеров
в сети не нужна. Если вы пользовались централизованными системами, где
практически на каждую операцию накладывается сетевая задержка, вы
оцените скорость работы с Git. Поскольку вся история проекта хранится
локально у вас на диске, большинство операций выглядят практически
мгновенными.
К примеру, чтобы показать историю проекта, Git-у не нужно скачивать её с сервера, он просто читает её прямо из вашего локального репози-
39
тория. Поэтому историю вы увидите практически мгновенно. Если вам
нужно просмотреть изменения между текущей версией файла и версией,
сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтобы запрашивать разницу у сервера
СУВ или качать с него старую версию файла и делать локальное сравнение.
Кроме того, работа локально означает, что мало чего нельзя сделать
без доступа к Сети или VPN. Если вы в самолёте или в поезде и хотите немного поработать, можно спокойно делать коммиты, а затем отправить их,
как только станет доступна сеть. Если вы пришли домой, а VPN клиент не
работает, всё равно можно продолжать работать. Во многих других системах это невозможно или же крайне неудобно. Например, используя Perforce,
вы мало что можете сделать без соединения с сервером. Работая с
Subversion и CVS, вы можете редактировать файлы, но сохранить изменения
в вашу базу данных нельзя (потому что она отключена от репозитория).
Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело.
3.1.8 Git следит за целостностью данных
Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта
функциональность встроена в сам фундамент Git и является важной составляющей его философии. Если информация потеряется при передаче
или повредится на диске, Git всегда это выявит.
Механизм, используемый Git для вычисления контрольных сумм, называется SHA-1 хеш. Это строка из 40 шестнадцатеричных знаков (0-9 и a-f),
которая вычисляется на основе содержимого файла или структуры каталога, хранимого Git. SHA-1 хеш выглядит примерно так:
24b9da6552252987aa493b52f8696cd6d3b00373
40
Работая с Git, вы будете постоянно встречать эти хеши, поскольку
они широко используются. Фактически, в своей базе данных Git сохраняет
всё не по именам файлов, а по хешам их содержимого.
3.1.9 Чаще всего данные в Git только добавляются
Практически все действия, которые вы совершаете в Git, только добавляют данные в базу. Очень сложно заставить систему удалить данные
или сделать что-то неотменяемое. Можно, как и в любой другой СУВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий.
Поэтому пользоваться Git — удовольствие, потому что можно экспериментировать, не боясь серьёзно что-то поломать.
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].
После регистрации — заведите репозиторий (зайдите во вкладку Repositories и нажмите на 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=<oneline, short, full, fuller> — команда для изменения параметров лога (в скобочках перечислены основные опции вывода);
—pretty=format: «%h — %an, %ar : %s» — команда для создания собственного формата вывода лога, которая может быть полезна, когда вы
создаёте отчёты для автоматического разбора (парсинга);
—since и –until =2.weeks — команда для ограничения вывода по времени, может быть за последние несколько дней, недель, месяцев, а также
часов, минут, секунд и пр.
На любой стадии может возникнуть необходимость что-либо отменить. Будьте осторожны, ибо не всегда можно отменить сами отмены. Это
одно из немногих мест в Git, где вы можете потерять свою работу, если
сделаете что-то неправильно.
Изучите работу с командой $ git commit —amend самостоятельно.
Git поддерживает большое количество команд, поэтому при возникновении вопросов — обязательно обращайтесь к рабочей документации,
набрав команду
$ git help
или для открытия html файла с помощью
$ git help git
Помимо этого, можно получить помощь на конкретную команду
набрав:
$ git help <command>
Работа с ветками будет рассмотрена в следующем разделе, т.к. её
наиболее удобно показать на программе, имеющей пользовательский ин-
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
Для того чтобы увидеть систему ветвления вашего проекта в SourceTree (см. рис. 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. После выполнения некоторых изменений слейте ветку Development и главную ветку master.
57
9. Отправьте изменения на GitHub.com.
10. Всю дальнейшую работу с лабораторными заданиями выполняйте при параллельном использовании версионного контроля. Любое изменение логически должно быть зафиксировано — делайте коммиты в репозиторий. При необходимости проведения определённых улучшений программы — создавайте дополнительные ветки, над которыми в дальнейшем
выполняйте слияние с главной веткой и фиксируйте промежуточные варианты в GitHub.com.
3.6 Список использованных источников
1. Git — Book [Электронный ресурс]. — URL: http://gitscm.com/book/ru/v1 (дата обращения 18.12.2014).
2. GitHub [Электронный ресурс]. — URL: https://github.com (дата обращения 18.12.2014).
3. Git — Downloading Package [Электронный ресурс]. — URL:
http://git-scm.com/download/win (дата обращения 18.12.2014).
4. gitignore/VisualStudio.gitignore [Электронный ресурс]. — URL:
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore (дата
обращения 18.12.2014).
5. Free Mercurial and Git Client for Windows and Mac | Atlassian SourceTree [Электронный ресурс]. — URL: http://www.sourcetreeapp.com/ (дата
обращения 18.12.2014).
6. Git — GUI Clients [Электронный ресурс]. — URL: http://gitscm.com/downloads/guis (дата обращения 18.12.2014).
7. A successful Git branching model// nvie.com [Электронный ресурс]. —
URL: http://nvie.com/posts/a-successful-git-branching-model/ (дата обращения
18.12.2014).
8. Удачная модель ветвления для Git // Хабрахабр [Электронный ресурс]. — URL: http://habrahabr.ru/post/106912/ (дата обращения 18.12.2014).