Основы Git. Как работает Git?

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

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

Как работать с Git?

В Git имеется много команд, поэтому разобьём их по теме и причине использования. Но начнём с того, что рассмотрим работу Git на локальной машине, ведь большая часть операций происходит именно там. После этого перейдём к многопользовательскому формату.

Вообще, с Git можно работать и через графический интерфейс (например, GitHub Desktop), и через командную строку. Командную строку изучить необходимо хотя бы потому, что она предоставляет больше возможностей, чем некоторые инструменты с интерфейсом.

Обычно, команды Git имеют следующий вид:

git <команда> <аргументы>

В качестве аргумента может быть путь к файлу. Также у команд бывают опции, обозначаемые --<опция> либо -<однобуквенная опция>. Они обеспечивают более детальную настройку действия команды. В нашем материале команды будут представлены в общем виде, а значит всё, что будет в <>, вы можете менять на собственные значения.

Кстати, если возникают затруднения с использованием той либо иной команды, рекомендуется открыть руководство посредством git help <команда>. Если просто нужно напоминание, применяйте git <команда> -h либо git <команда> --help (в Git -h и --help имеют одинаковое значение).

Установка Git

Если вы пользуетесь Windows, качайте Git отсюда. Что касается macOS, то здесь Git поставляется как часть инструмента командной строки XCode. Наличие Git можно проверить, открыв терминал и набрав git --version. Для Linux используйте команду sudo apt install git-all либо sudo dnf install git-all.

Настраиваем конфигурационный файл

Сразу после установки Git нужно настроить имя пользователя и email, ведь они используются для идентификации. Данные настройки будут сохранены в конфигурационном файле.

Вы можете отредактировать файл .gitconfig напрямую с помощью редактора или, используя команду git config --global --edit. Чтобы отредактировать отдельные поля, подойдёт git config --global <поле> <значение> — здесь нас интересуют поля user.email и user.name.

Кроме того, есть возможность настройки текстового редактора для написания сообщений коммитов — это поле core.editor. По умолчанию применяется системный редактор. Поле commit.template служит для указания шаблона, который будет задействоваться при каждом коммите.

Есть и много других полей, но самое полезное — alias (привязывает команду к псевдониму). К примеру, git config --global alias.st "status -s" позволит использовать git st вместо git status –s.

А git config --list выведет все поля с их значениями из конфигурационного файла.

Создание Git-репозитория

Чтобы инициализировать новый репозиторий .git используют команду git init. Если хотите скопировать уже существующий репозиторий — git clone <адрес репозитория>.

История коммитов в Git

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

Ссылаться можно как через контрольную сумму коммита, так и через его позицию относительно HEAD. К примеру, HEAD~4 будет ссылаться на коммит, находящийся 4-мя коммитами ранее HEAD.

Система файлов в Git

Git может отслеживать файлы в 3-х основных разделах: — рабочая директория (речь идёт о файловой системе вашего ПК); — область подготовленных файлов (это staging area, где хранится содержание следующего коммита); — HEAD (последний в репозитории коммит).

Как просматривать изменения в файловых системах?

Для этого используют команду git status. Она отображает все файлы, которые различаются между 3-мя отделами. Файлы имеют четыре состояния: 1) untracked (неотслеживаемый). Находится в рабочей директории, но его нет ни в HEAD, ни в области подготовленных файлов. Можно сказать, что Git о нём не знает; 2) modified (изменён). В рабочей директории находится его более новая версия по сравнению с той, которая хранится в HEAD либо в области подготовленных файлов (при этом изменения не находятся в следующем коммите); 3) staged (подготовлен). В области подготовленных файлов и в рабочей директории есть более новая версия, если сравнивать с хранящейся в HEAD, но файл уже готов к коммиту; 4) без изменений. Во всех разделах содержится одна версия файла, то есть в последнем коммите находится актуальная версия.

Чтобы посмотреть не изменённые файлы, а непосредственно изменения, можно использовать: — git diff — для сравнения рабочей директории с областью подготовленных файлов; — git diff --staged — для сравнения области подготовленных файлов с HEAD.

В случае применения аргумента <файл/папка> diff покажет изменения лишь для указанных вами папок или файлов, к примеру:

git diff src/

Игнорирование файлов

Иногда нам не надо, чтобы Git отслеживал все файлы в репозитории, ведь в их число могут входить: — файлы с конфиденциальной информацией; — огромные бинарные файлы; — специфичные файлы; — файлы сборок, генерируемые после каждой компиляции.

Для игнорирования предусмотрен файл .gitignore, где отмечаются файлы для игнорирования.

Коммиты

Основой истории версий являются коммиты. Для работы с ними используют git commit — эта команда откроет текстовый редактор для ввода сообщения коммита. Кроме того, она принимает следующие аргументы: • -m — позволяет написать сообщение, не открывая редактор, то есть вместе с командой; • -a — служит для переноса всех отслеживаемых файлов в область подготовленных файлов и включения их в коммит (даёт возможность перед коммитом пропустить git add); • --amend — заменяет последний коммит новым изменённым коммитом. Это бывает полезно, когда вы неправильно наберёте сообщение последнего коммита либо забудете включить в него нужные файлы.

Ряд советов по коммитам: — коммитьте часто; — одно изменение — один коммит, но не коммитьте слишком незначительные изменения (в большом репозитории они могут засорить историю); — комментируя сообщение о коммите, логически дополняйте фразу this commit will ___ и не используйте более 50 символов.

Удалённые серверы

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

Для вывода списка удалённых репозиториев нужна команда git remote –v. С её помощью мы не только загружаем копию репозитория, но и отслеживаем удалённый сервер, находящийся по указанному адресу (ему присваивается имя origin).

Другие часто употребляемые команды: • git remote add <имя> <url> — добавляется удалённый репозиторий с заданным именем; • git remote remove <имя> — удаляется удалённый репозиторий с заданным именем; • git remote rename <старое имя> <новое имя> — переименовывается удалённый репозиторий; • git remote set-url <имя> <url> — репозиторию с именем присваивается новый адрес; • git remote show <имя> — показывается информация о репозитории.

Следующий список нужен для работы с удалёнными ветками: • git fetch <имя> <ветка> — для получения данных из ветки заданного репозитория; • git pull <имя> <ветка> — сливает данные из ветки; • git push <имя> <ветка> — для отправления изменения в ветку заданного репозитория. Когда локальная ветка отслеживает удалённую, достаточно использовать git push или git pull.

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

Ветвление в Git

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

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

Стандартные команды при ветвлении в Git: • git branch <имя ветки> — для создания новой ветки с HEAD, указывающим на HEAD. Если аргумент <имя ветки> передан не будет, команда выведет список всех имеющихся локальных веток; • git branch -d <имя ветки> — для удаления ветки; • git checkout <имя ветки> — для переключения на эту ветку. Если хотим создать новую ветку перед переключением, можем передать опцию –b.

И локальный, и удалённый репозиторий могут иметь много веток, поэтому при отслеживании на деле отслеживается удалённая ветка, то есть git clone привязывает ветвь master к ветви origin/master удалённого репозитория.

Парочка команд для привязывания к удалённой ветке: • git branch -u <имя удалённого репозитория>/<удалённая ветка> —текущая ветка привязывается к указанной удалённой ветке; • git checkout --track <имя удалённого репозитория>/<удалённая ветка> — аналогично; • git checkout -b <ветка> <имя удалённого репозитория>/<удалённая ветка> — создаётся новая локальная ветвь и начинает отслеживать удалённую; • git checkout <удалённая ветка> — создаётся локальная ветвь с таким же именем, как и у удалённой, плюс начинает её отслеживать; • git branch --vv — служит, чтобы показать локальные и отслеживаемые удалённые ветки.

Совмещение веток

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

Слияние

Включает в себя создание нового коммита, основанного на общем коммите-предке 2-х ветвей, указывает на оба HEAD. Для осуществления слияния нужно перейти на основную ветки и использовать команду git merge <тематическая ветка>.

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

Маркеры разрешения конфликта:

<<<<<<< HEAD:index.html
 Everything above the ==== is the version in master. 
 =======
 Everything below the ==== is the version in the test branch. 
 >>>>>>> test:index.html

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

Перемещение

Осуществляется вместо совмещения 2-ух веток коммитом слияния. Перемещение заново воспроизводит коммиты тематической ветви в виде набора новых коммитов базовой ветви, что обеспечивает более чистую историю коммитов.

Чтобы выполнить перемещение, используют команду git rebase <основная ветка> <тематическая ветка>. Она воспроизводит изменения тематической ветви на основной. При этом HEAD тематической ветви указывает на последний воспроизведённый коммит.

Совет: перемещайте изменения лишь на вашей приватной локальной ветке. Не стоит перемещать коммиты, от которых ещё кто-то зависит.

Если хотите откатить коммит: — git revert <коммит> — создаёт новый коммит, который отменяет изменения, но сохраняет историю; — git reset <коммит> — перемещает указатель HEAD, и создаёт более чистую историю, как будто коммита никогда не было. Но это также значит, что вы не сможете вернуться обратно к изменениям, если решите, что отмена была лишней. В общем, чище — не значит лучше!