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

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

А начнём мы с основы. Что вообще такое система контроля версий?

Система контроля версий (Version Control System, VCS) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.

Виды:

• Локальные VCS используют локальную БД для хранения информации об изменениях.

• Централизованные системы контроля версий (CVCS) используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища.

• Распределённые системы контроля версий (DVCS) — клиенты скачивают снимок всех файлов (состояние файлов на определённый момент времени), копируя удалённый репозиторий.

Что такое Git?

Git — это система контроля версий (Version Control System, VCS), которая помогает отслеживать изменения в коде, возвращаться к старым версиям и работать над проектом вместе с другими разработчиками. Главное отличие Git от многих других VCS в том, что он распределённый: у каждого разработчика есть полноценная копия репозитория, включая всю историю проекта.

Это даёт сразу несколько преимуществ:

• можно работать офлайн, без постоянного доступа к серверу;

• есть «резервная копия» всего проекта у каждого участника;

• операции выполняются очень быстро, потому что всё делается локально.

  

Git VS Другие системы контроля версий

Большинство других систем хранят информацию в ��иде списка изменений в файлах. Эти системы (CVS, Subversion, Perforce, Bazaar и т. д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, основанным на различиях (diff)).

Git работает иначе: он хранит снимки (snapshots). Каждый раз, когда вы делаете commit, Git сохраняет текущее состояние всех файлов, как миниатюрную файловую систему. Если файл не менялся, Git не копирует его заново, а делает ссылку на уже сохранённую версию.

Основные объекты Git

Внутри Git всё строится вокруг четырёх типов объектов:

• Blob (Binary Large Object) — это «кусок данных», хранящий содержимое файла. Blob не знает имени файла, только его содержимое и хэш. То есть, если файл одинаковый в двух коммитах — blob будет один.

• Tree (дерево) — структура, которая собирает blob’ы и другие деревья. Она хранит имена файлов и их организацию по папкам. Tree можно представить как снимок директории проекта.

• Commit — объект, который «собирает» снимок проекта: указывает на дерево, хранит автора, дату, комментарий и ссылку на предыдущий commit.

• Tag (тег) — ярлык, который можно «повесить» на commit, чтобы отметить, например, релиз. Теги могут быть простыми (указывают на commit) или аннотированными (содержат имя, дату и описание).

Эти объекты связаны между собой через хэши (SHA-1 — уникальные «отпечатки пальцев» для содержимого), что делает историю неизменяемой и защищённой от подмены.

Состояния коммитов:

• Рабочая директория — здесь ты редактируешь файлы проекта на своём компьютере. Например, добавил новую функцию в код.

• Index (Stage) — это как «корзина для покупок» в интернет-магазине — ты выбираешь, какие изменения взять в будущий коммит. Добавление делается командой git add. Можно не коммитить всё сразу, а выбрать только нужные файлы.

• Локальный репозиторий (.git) — это «база данных» внутри папки .git, где сохраняется вся история проекта. Когда ты делаешь git commit, изменения из Index фиксируются и превращаются в новый коммит. Теперь у тебя есть «снимок проекта» в истории.

• Удалённый репозиторий — обычно это GitHub, GitLab или Bitbucket — место, где лежит общая версия проекта для команды. Командой git push ты «делишься» своими изменениями с другими. Командой git pull ты «подтягиваешь» изменения, которые сделали другие.

  

Жизненный цикл файлов в Git:

Файл в Git может находиться в нескольких состояниях:

• Untracked — Git «видит», что такой файл существует, но не следит за изменениями в нём.

• Staged — после выполнения команды git add файл попадает в staging area, то есть в список файлов, которые войдут в коммит.

• Unmodified — довольно широкое по смыслу: в него попадают файлы, которые уже были зафиксированы с помощью git commit, а также файлы, которые были добавлены в staging area командой git add.

• Modified — файл изменён по сравнению с последним commit.

  

Что такое .gitignore?

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

Зачем нужен .gitignore?

В проекте часто есть файлы, которые:

• создаются автоматически (например, логи, временные файлы, кэш),

• специфичны для твоего компьютера (настройки IDE, локальные конфиги),

• не нужны в истории репозитория (собранные бинарники, архивы).

Чтобы такие файлы не засоряли репозиторий, их и указывают в .gitignore.

Важный момент

☝️.gitignore работает только для неотслеживаемых файлов. Если файл уже был добавлен в Git, то просто добавление его в .gitignore не уберёт его из репозитория. Для этого нужно удалить его из индекса (git rm --cached).

Ветки Git

• Репозиторий может содержать множество веток, в которых могут быть отличия между файлами.

• Основная ветка — master.

• На основе любой ветки можно сделать новую ветку.

• Любую ветку можно соединить с любой другой веткой.

• Можно посмотреть разницу файлов и решить конфликты.

  

Основные команды Git

Работа с репозиторием:

• git init — создание нового локального репозитория.

• git clone <url> — клонирование удалённого репозитория.

• git tag — работа с тегами (создание/просмотр).

Удалённые репозитории и синхронизация:

• git fetch — забрать изменения без слияния.

• git pull — влить последние изменения в локальный репозиторий.

• git push — отправить изменения в удалённый репозиторий.

• git push --force — принудительная публикация изменений.

Работа с ветками:

• git branch — просмотр всех веток.

• git checkout -b <branch> — создать и переключиться на ветку.

• git checkout <branch> — переключение ветки.

• git switch <branch> — переключение ветки (альтернатива checkout).

• git checkout <commit> / git checkout <remote>/<branch> — переход в конкретный коммит/удалённую ветку.

• git merge <branch> — слить указанную ветку в текущую.

• git merge --abort — отменить проблемный merge.

• git cherry-pick <commit> — перенести один коммит.

• git rebase <branch> — перебазирование.

• git rebase --onto <target_branch> <start> <end> — перебазирование диапазона.

• git rebase --abort — отменить rebase.

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

• git add <file> — добавить в индекс.

• git rm <file> — удалить файл из индекса/репозитория.

• git commit -m "msg" — создать коммит.

• git commit --amend — поправить последний коммит.

• git diff — показать различия.

Откаты/восстановление:

• git reset --soft <commit> — перемещает ветку на <commit>, оставляет всё в staged.

• git reset --mixed <commit> (по умолчанию, т. е. просто git reset <commit>) — двигает ветку и разстейдживает изменения.

• git reset --hard <commit> — полный откат: двигает ветку, чистит staged и рабочие файлы до состояния <commit>.

• git revert <commit> — не переписывает историю: создаёт новый коммит, который отменяет изменения указанного <commit>.

Работа с историей:

• git status — состояние рабочей директории/индекса.

• git show <object> — показать объект/коммит.

• git log — история коммитов.

• git reflog — журнал перемещений ссылок.

• git blame <file> — кто и когда менял строки.

Временное сохранение (stash):

• git stash — убрать незакоммиченные изменения «в шкаф».

• git apply — применить отложенные изменения.

• git pop — применить и удалить из stash.

Поиск и анализ:

• git grep <pattern> — поиск по коду.

• git bisect — поиск коммита, сломавшего сборку.

Некоторые вопросы по командам Git, которые вас могут спросить на собеседовании.

В чём отличие git pull от git fetch?
Ответ: git fetch загружает изменения из удалённого репозитория в локальный, но не применяет их. Git pull не только загружает последние изменения из удалённого репозитория, но и автоматически сливает их с текущей локальной веткой.

В чём отличие git reset --hard от git revert?
Ответ: git reset двигает указатель ветки на выбранный коммит, удаляя последующие изменения. Git revert — создаёт новый коммит, который отменяет изменения предыдущего коммита, сохраняя при этом всю историю изменений.

Слияние, ребейз и выборочные коммиты в Git

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

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

Git Cherry Pick — это команда в системе контроля версий Git, которая позволяет выбирать и применять (переносить) коммиты из одной ветки в другую. Эта команда полезна, когда вы хотите применить только определённые коммиты из одной ветки в другую, а не весь набор изменений. При переносе могут возникнуть конфликты, и нужно их будет решать.

Что такое Pull request?

Pull request (или PR) — это запрос на внесение изменений в код перед слиянием с основной веткой репозитория в Git. В PR видно коммиты и diff, ведётся обсуждение и ревью, запускаются проверки (CI). После одобрений PR вливают в нужную ветку или закрывают без слияния. ☝️Важно: PR — это не команда Git и не git pull. Это заявка в веб-интерфейсе Git-хостинга (GitHub/Bitbucket) на вливание вашей ветки в целевую ветку. В GitLab Pull request называется Merge Request (MR).

Что такое Race condition

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

Почему Git — нынешний стандарт контроля версий?

После появления Git он быстро вытеснил конкурентов (CVS, SVN, Perforce) и стал стандартом в индустрии. И вот почему:

• Скорость — большинство операций выполняются локально.

• Надёжность — благодаря хэшам данные защищены от подмены.

• Удобные ветки и слияния — разработчики могут вести десятки параллельных фич.

• Распределённость — у каждого есть полная копия проекта.

• Сообщество и экосистема — GitHub, GitLab, Bitbucket сделали Git ещё удобнее, добавив графические интерфейсы, CI/CD и инструменты командной работы.

А на последок полезные ресурсы, благодаря которым вы точно поймете, как работает Git:
Pro Git book - самая полная книга по Git, переведенная на русский язык.
Как разобраться в Git - полезная статья, в которой собраны основные команды git и не только.
Игра для освоения Git - очень полезная игра, чтобы понять принципы работы Git. Пройдя ее до конца вы точно сможете разобраться, как пользоваться git и не напортачить в реальном проекте.

Заключение
Git работает не как блокнот изменений, а как система снимков. Под капотом у него блобы, деревья, коммиты и теги, которые образуют надёжную и быструю историю. Благодаря этим идеям Git стал стандартом индустрии и основой для DevOps-практик.