Система контроля версий Git

• Git — распределённая система контроля версий
• Особенности хранения файлов Git
• Работа с файлами
• Установка Git
• Репозитории Git
• Отслеживание изменений и запись в репозиторий
• Ветвление
• Слияние изменений
• Работа с удалёнными ветками

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

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

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

Особенности хранения файлов Git

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

У Git есть три основных состояния, в которых могут находиться файлы: зафиксированное (committed), изменённое (modified) и подготовленное (staged). Зафиксированный файл уже сохранён в локальной базе. Изменённые файлы поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.

Работа с файлами

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

Основная работа с Git выглядит так:

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

Установка Git

Если требуется установить Git под Linux как бинарный пакет, можно использовать обычный менеджер пакетов дистрибутива, например, apt-get:

apt-get install git

Существует несколько способов установки Git на Mac. Самый простой — установить Xcode Command Line Tools. В версии Mavericks (10.9) и выше можно добиться этого, впервые выполнив git в терминале. Если Git не установлен, будет предложено его установить.

Для установки Git в Windows официальная сборка доступна для скачивания на официальном сайте Git.

Инструкции о дополнительных возможностях установки доступны для Linux, Mac, Windows.

Репозитории Git

Репозиторий, или проект Git, включает в себя всю коллекцию файлов и каталогов, связанных с проектом, а также историю изменений каждого файла. История файлов отображается в виде моментальных снимков состояний файлов, называемых коммитами, а коммиты существуют в виде связанных списков и могут быть организованы в несколько линий разработки, называемых ветвями. Можно работать с командной строкой или другими легкими в использовании интерфейсами, чтобы таким образом в репозитории git взаимодействовать с историей, клонировать, создавать ветки, фиксировать, сливать, сравнивать изменения между версиями кода и многое другое.

Если нужно начать использовать Git для существующего проекта, то в первую очередь необходимо перейти в директорию проекта и в командной строке ввести

git init

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

Второй способ получить Git-репозиторий — это клонировать его:

git clone https://github.com/libgit2/libgit2

Эта команда создаёт директорию libgit2, инициализирует в ней поддиректорию .git, скачивает все данные для этого репозитория и создаёт рабочую копию последней версии. Если зайти в новую директорию libgit2, то можно найти в ней файлы проекта, готовые для работы или использования.

Отслеживание изменений и запись в репозиторий

Основной способ определить, какие файлы в каком состоянии находятся — это команда:

git status

Она информирует о состоянии файлов в репозитории: о неотслеживаемых, изменённых или подготовленных к коммиту.

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

git add <путь_к_файлу_или_директории>

Если результат git status недостаточно информативен — нужно посмотреть детали того, что конкретно поменялось в файлах — можно использовать команду:

git diff

git diff работает только для измененных файлов, которые ещё не были добавлены в индекс. Это значит, что для внесённых изменений ещё не выполнена команда git add.

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

git diff --cached

Когда индекс приведён к желаемому состоянию, можно зафиксировать изменения. Самый простой способ —  набрать git commit:

git commit

После этой команды откроется окно редактора, в котором можно ввести комментарий к коммиту. Если нужно добавить комментарий сразу, можно воспользоваться аргументом -m:

git commit -m "Добавлена лицензия"

Следует обратить внимание, что всё, что до сих пор не проиндексировано —  любые созданные или изменённые файлы, для которых не была выполнена команда git add после момента редактирования — не будут включены в коммит.

Чтобы посмотреть историю коммитов, можно использовать команду:

git log

Ветвление

При использовании ветвления разработчик отклоняется от основной линии разработки и продолжает работу независимо от неё.

Команда создания новой ветки:

git branch <название_ветки>

В результате создаётся новый указатель на тот же самый коммит, в котором находится разработчик.

Команда git branch только создаёт новую ветку. Чтобы на ветку переключиться и работать уже в ней, можно использовать команду:

git checkout <название_ветки>

Альтернативный вариант:

git switch <название_ветки>

Можно выполнить оба действия в одну команду: создать новую ветку и сразу переключиться на неё:

git checkout -b <название_ветки>

Альтернативный вариант:

git switch -C <название_ветки>

Слияние изменений

Если требуется объединить изменения, сделанные в разных ветках в одну, можно воспользоваться командой git merge. Например:

git merge testing

Эта команда, выполненная на основной ветке проекта master, объединяет ветки master и testing.

Иногда процесс не проходит гладко. Если была изменена одна и та же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Вместо этого он остановит процесс слияния и предложит разрешить конфликт. Чтобы увидеть, какие файлы не объединены, можно запустить git status. Далее можно внести изменения вручную и потом зафиксировать изменения. Также можно командой git mergetool запустить графический инструмент для разрешения конфликтов. Для этого предварительно нужно настроить git, а именно указать в конфигурации merge.tool путь к исполняемому файлу графического инструмента для разрешения конфликтов. Иначе команда git mergetool не отработает.

Работа с удалёнными ветками

Удалённые ветки — это указатели на состояние веток в удалённых репозиториях (remote branches). Ветки, которые физически удалены и больше не существуют, сюда не относятся. Удалённые ветки выглядят как <имя_удал._репоз.>/<ветка>. Например, если нужно посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, следует проверить ветку origin/master.

Для синхронизации работы с удалённым сервером выполняется команда:

git fetch origin

Она извлекает оттуда все данные, которых в локальном репозитории ещё нет, но не сливает удалённую ветку с аналогичной локальной. Для слияния веток можно использовать:

git merge origin/master

или можно заменить набор команд fetch и merge одной:

git pull

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

git push origin master

В команде push следует указать сервер (например, origin) и ветку (например, master).