1.1 Введение — О системе контроля версий

Эта глава о том, как начать работу с Git. Вначале изучим основы систем контроля версий, затем перейдём к тому, как запустить Git на вашей ОС и окончательно настроить для работы. В конце главы вы уже будете знать, что такое Git и почему им следует пользоваться, а также получите окончательно настроенную для работы систему.

О системе контроля версий

Что такое «система контроля версий» и почему это важно? Система контроля версий — это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Для контроля версий файлов в этой книге в качестве примера будет использоваться исходный код программного обеспечения, хотя на самом деле вы можете использовать контроль версий практически для любых типов файлов.

Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее СКВ) — как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое. Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий.

Локальные системы контроля версий

Многие люди в качестве метода контроля версий применяют копирование файлов в отдельный каталог (возможно даже, каталог с отметкой по времени, если они достаточно сообразительны). Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели.

Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.

Одной из популярных СКВ была система RCS, которая и сегодня распространяется со многими компьютерами. RCS хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени.

Централизованные системы контроля версий

Следующая серьёзная проблема, с которой сталкиваются люди, — это необходимость взаимодействовать с другими разработчиками. Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (ЦСКВ). Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. Применение ЦСКВ являлось стандартом на протяжении многих лет.

Такой подход имеет множество преимуществ, особенно перед локальными СКВ. Например, все разработчики проекта в определённой степени знают, чем занимается каждый из них. Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать ЦСКВ, чем оперировать локальными базами данных на каждом клиенте.

Несмотря на это, данный подход тоже имеет серьёзные минусы. Самый очевидный минус — это единая точка отказа, представленная централизованным сервером. Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками. Если жёсткий диск, на котором хранится центральная БД, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё — всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. Локальные СКВ страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё.

Распределённые системы контроля версий

Здесь в игру вступают распределённые системы контроля версий (РСКВ). В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) — они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.

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

Что такое Git: объясняем на схемах

Команды разработчиков пользуются системой контроля версий. Чаще всего это Git. Разбираемся, что это значит, зачем нужно и как устроено.

Git — это система для управления версиями исходного кода программ. В статье мы познакомимся с её основными возможностями, покажем отличие от GitHub и объясним, зачем Git новичку. Ещё вы узнаете, с чего начать обучение и почему не стоит тратить время на альтернативные программы.

Git — это система коммитов

Представьте ситуацию: геймер доходит до финала, проигрывает и возвращается к началу уровня — попадает в ближайшую контрольную точку игры, где разработчики разрешили сохраниться. Если мы уберём контрольные точки, после каждого проигрыша придётся начинать игру заново.

В программировании за сохранение кода в контрольных точках отвечает система контроля версий — специальная технология, которую можно подключить к любому проекту. Система контроля версий страхует от ошибок и возвращает код в то состояние, когда всё работало.

Контрольные точки называются коммитами . Один коммит — это пакет изменений, хранящий информацию с добавленными, отредактированными или удалёнными файлами кода. В один коммит принято добавлять не более десяти изменений — так получается длинная история версий, которая позволяет в случае ошибки откатиться с минимальной потерей работоспособного кода.

Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.

Git — это комплекс связанных веток

Коммиты располагаются на master-ветке — основной версии проекта, которая после завершения работы превратится в продукт.

Система контроля версий позволяет создавать ответвления от master-ветки и экспериментировать с проектом, не мешая другим участника команды.

Возьмём предыдущую схему, где мы обнаружили ошибку и откатились на один коммит назад. Чтобы поправить код, создадим несколько дополнительных веток и в каждой протестируем разные варианты решения проблемы. Когда решение найдено, ветку с правильным кодом переносим в master-ветку и сохраняем коммит. Лишние ветки оставляем или удаляем, поскольку они не влияют на проект и скрыты от других разработчиков — это ваш личный черновик.

Git — это инструмент совместного создания кода

Часто бывает так: разработчики отделяются от master-ветки и работают над частью проекта самостоятельно — например, чтобы протестировать дополнительные функции. Но не могут продолжить, пока кто-то из команды не допишет код.

Система контроля версий позволяет не ждать обновления master-ветки и разрешает всем участникам команды свободно перемещаться между ветками других разработчиков для копирования нужных фрагментов кода.

Бывают и обратные ситуации, когда несколько разработчиков одновременно дописывают код, заливают его в master-ветку и сталкиваются с конфликтом — один файл получает несколько несогласованных изменений. В этом случае Git попробует автоматически исправить ошибки. Если не получится, разработчики это увидят и смогут поправить код вручную.

Git — это распределённая система версий

Системы контроля версий бывают локальными, централизованными или распределёнными.

• Локальная система хранит файлы на одном устройстве, централизованная использует общий сервер, а распределённая — общее облачное хранилище и локальные устройства участников команды. В локальной системе удобно работать с большими проектами, но сложно взаимодействовать с удалённой командой.
• В централизованной системе налажена удалённая работа, но всё привязано к одному серверу. Любой сбой или взлом может повредить файлы проекта.
• В распределённой системе налажена удалённая работа. Если с файлами основного репозитория что-то случится — проект легко восстановить из копии любого участника команды.

Из-за удобства и гибкости распределённая система версий Git считается современным форматом. Это стандарт для большинства ИТ-команд.

Git — это не GitHub

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

Git — это самая популярная система контроля версий, а GitHub — онлайн-хранилище кода. Git и GitHub настроены на взаимодействие и поэтому часто используются как единый механизм работы с проектом.

Если нужно, Git можно заменить альтернативной программой контроля версий, а GitHub — другим онлайн-хранилищем кода. Большинству работодателей это не нужно, поскольку знакомство с другими сервисами отнимает время и неудобно многим разработчикам.

Зачем новичку учить Git

Git используется в большинстве компаний, где над проектом работает хотя бы два разработчика:

• Новый человек приходит в компанию и клонирует репозиторий проекта на ПК.
• Получает задачу, создаёт новую ветку и пишет код.
• Когда всё готово — отправляет запрос на добавление кода в master-ветку.
• Другие разработчики смотрят код, оставляют комментарии и указывают на ошибки.
• Новичок дорабатывает код, обновляет master-ветку и переходит к следующей задаче.

Это общая схема того, как проходит командная работа в проекте. В ней не учтены правила использования Git, которые каждая команда пишет под себя. Например, у каждой команды свой порядок проверки кода и свои критерии его готовности для добавления в master-ветку.

Знание Git и знание правил использования Git в команде — это два разных навыка, которые можно сравнить с умением ездить на автомобиле и знанием правил дорожного движения. Если умеете управлять автомобилем — вам проще сконцентрироваться и быстро выучить правила. С Git аналогичная ситуация: если вы умеете управлять системой контроля версий, то можете сразу влиться в проект, не отвлекаться на второстепенные вещи и сосредоточиться на качестве кода.

С чего начать: 3 шага, чтобы освоить Git

1. Посмотрите наш вебинар по основам работы с Git:

Установка и использование системы контроля версий Git в Windows

Виртуальный сервер на базе Windows

• Лицензия включена в стоимость
• Тестирование 3-5 дней
• Безлимитный трафик

В инструкции описан процесс загрузки, установки системы контроля версий Git на сервера с операционной системой Windows и подключения к удаленному репозиторию GitHub.

Что это такое?

Git — одна из самых популярных систем контроля версий, используется разработчиками, для контроля изменений в своих разработках и проектах. Изначально создан для использования на Linux-подобных операционных системах, но позднее, из-за удобства и популярности для Windows был написан специальный эмулятор, поддерживающий функционал Git’a.

Загрузка и установка

Загрузите установщик с официального сайта. Загрузка начнется автоматически.

Перейдите в папку “Downloads” и запустите на исполнение загруженный файл.

Укажите путь до каталога в который будет установлен Git.

Чтобы на рабочем столе была иконка Git, на следующем шаге отметьте галочкой “On the Desktop”.

Введите имя директории, которая будет создана в Start Menu. При необходимости можно изменить путь с помощью кнопки Browse.

Выберете способ использования из командной строки:

• Use Git from Git Bash only — использование только из командной строки Bash.
• Use Git from the Windows Command Prompt — использование командной строки Bash, а также минимальный набор команд Git из консоли Windows.
• Use Git and optional Unix tools from the Windows Command Prompt — использование Git и утилит Unix из командной строки Windows, в этом случае будут перезаписаны некоторые утилиты Windows, например find и sort.

Выберете библиотку, которая будет использована при подключении по протоколу HTTPS:

• OpenSSL — сертификаты сервера будут проверяться с использованием Unix-файла ca-bundle.crt.
• Windows Secure Channel — сертификаты сервера будут проверяться с использованием стандартной библиотеки Windows.

Убедитесь, что вы выбрали способ обработки окончания строк «Checkout Windows-style, commit Unix-style line endings». Это значение гарантирует, что Git преобразует LF в CRLF при проверке текстовых файлов. При выполнении текстовых файлов CRLF также преобразуется в LF. Это мера совместимости для защиты новых строк в текстовых файлах, что позволяет легко работать с текстовыми файлами в Windows и на платформах Unix.

Примечание: LF и CRLF — управляющий символ для переноса строки в Unix и Windows соответственно.

Далее необходимо сконфигурировать используемый терминал:

• MinTTY — терминал Unix;
• Windows — стандартный терминал Windows.

Отметьте галочками нужные вам дополнительные функции:

• File system caching — кэширование файловой системы.
• Git Credential Manager — включить менеджер учетных данных.
• Symbolic links — разрешить символьные ссылки.

Нажмите кнопку Install.

Начнется процесс установки.

Подключение к удаленному репозиторию

Откройте каталог с файлами, которые необходимо отслеживать в системе контроля версий и выложить на GitHub. В пустую часть каталога нажмите правой кнопкой мыши и выберете Git Bash Here.

Перед вами откроется приглашение командной строки в зависимости от настроек.

Для настройки необходимо указать ваше имя и электронную почту:

git config —global user.email «you@example.com»
git config —global user.name «Ваше имя»

Для того чтобы начать отслеживать содержимое папки в системе, выполните команды:

git init
git add

Выполните первый коммит:

git commit -m «Init»

Чтобы добавить изменения, например, на github выполните действие:

git remote add origin https://github.com/пользователь/репозиторий.git
git push -u origin master

git remote add gitlab https://server/namespace/project.git
git push -u gitlab master

Перед вами откроется окно входа (консольное или стандартное окно Windows). В качестве пользователя укажите ваш логин на GitHub, репозиторий — название существующего репозитория.

Аутентификация по SSH-ключам

Выполнить подключение к удаленному репозиторию можно по протоколу SSH с помощью приватного и публичного ключа. Чтобы сгенерировать пару, выполните команду в консоли GitBash, указав ваш реальный почтовый адрес:

ssh-keygen -t rsa -b 4096 -C «email@example.com»

В процессе генерации вам будет предложено указать директорию и имя файла для ключа, примите значение по умолчанию, нажав Enter. Далее, при желании можно указать ключевую фразу в качестве дополнительной защиты, при ее отсутствии нажмите Enter. В результате будут сгенерированы ключи.

eval $(ssh-agent -s)

Вы увидите идентификатор процесса.

Добавьте ключи к ssh-агенту:

Теперь нужно добавить ключ к удаленному серверу Git. Заходим на сервер Git и в настройках добавляем SSH-ключ.

Например, на сервере GitHub это можно сделать следующим образом: откройте Settings -> SSH and GPG keys,нажмите New SSH key. В поле Title введите понятное название, в поле Key вставьте публичный ключ (содержимое файла

/.ssh/id_rsa.pub). Нажмите Add SSH key.

В результате у вас появится новый ключ.

Для проверки настроек выполните команду:

ssh -T git@github.com

Если все настроено верно, то вы увидите следующее сообщение.