Git: полный путеводитель — от первого коммита до продвинутых workflow

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

Что такое Git и зачем он нужен

В 2005 году Линус Торвальдс создал Git для управления исходным кодом ядра Linux. До этого команда использовала проприетарную систему BitKeeper, но после конфликта с её владельцами Торвальдс написал собственную VCS за две недели. Главные требования: скорость, поддержка нелинейной разработки (тысячи параллельных веток) и полная распределённость.

В отличие от централизованных систем вроде SVN или CVS, где есть единственный сервер с полной историей, Git даёт каждому разработчику полную копию репозитория — со всей историей коммитов, ветками и тегами. Это означает, что вы можете работать офлайн, создавать ветки мгновенно и не зависеть от доступности сервера. Mercurial — ещё одна распределённая VCS — решал те же проблемы, но Git победил благодаря скорости, гибкости ветвления и экосистеме GitHub.

Главное преимущество распределённой модели — отказоустойчивость и скорость. Все операции, кроме push/pull, выполняются локально: создание ветки, коммит, просмотр истории, diff — всё работает мгновенно без сетевого подключения. Если центральный сервер упадёт, любой клон — полная резервная копия. В централизованных системах потеря сервера означает потерю всей истории.

Сегодня Git используют более 95% разработчиков по данным Stack Overflow Developer Survey. Но Git — это только инструмент контроля версий, а не платформа для совместной работы. GitHub, GitLab и Bitbucket — это платформы, построенные вокруг Git. Подробнее о том, в чём разница между Git и GitHub, читайте в отдельной статье.

Установка, настройка и первый репозиторий

Git доступен на всех основных платформах. На macOS проще всего установить через Homebrew: brew install git. На Linux — через пакетный менеджер: sudo apt install git (Ubuntu/Debian) или sudo dnf install git (Fedora). На Windows — через официальный установщик с git-scm.com или менеджер пакетов: choco install git. Подробный разбор всех шагов — от установки до первых команд.

После установки убедитесь, что Git доступен, командой git --version — она выведет текущую версию и подтвердит, что всё работает.

После установки первым делом настройте имя и email — они будут записаны в каждый ваш коммит:

			git config --global user.name "Ivan Petrov"
git config --global user.email "ivan@example.com"

# Опционально: редактор для коммитов и rebase
git config --global core.editor "code --wait"

# Проверить текущие настройки
git config --list
		

Теперь можно создать первый репозиторий. Команда git init превращает обычную папку в Git-репозиторий, создавая скрытую директорию .git со всей служебной информацией:

			mkdir my-project && cd my-project
git init
# Initialized empty Git repository in /home/user/my-project/.git/
		

Файлы в Git проходят через три состояния: рабочая директория (working directory) — где вы редактируете файлы; область подготовки (staging area, она же index) — промежуточное хранилище для следующего коммита; репозиторий (.git) — постоянное хранилище всех коммитов. Понимание этого цикла — фундамент работы с Git.

Ещё несколько полезных настроек на старте: git config --global init.defaultBranch main — новые репозитории будут создаваться с веткой main вместо master. git config --global alias.st status — создаёт сокращение git st вместо полного git status. Алиасы экономят время при ежедневной работе: co для checkout, br для branch, lg для красивого лога.

Основные команды: add, commit, log, diff

Ежедневная работа с Git строится вокруг пяти команд. git add перемещает изменения в staging area. git commit фиксирует снимок. git status показывает текущее состояние. git log выводит историю. git diff показывает разницу между версиями. Если вы освоите только их — уже закроете 80% повседневных задач. Подробный быстрый старт по основным операциям собран в отдельном материале.

			# Создаём файл и добавляем в staging
echo "Hello, Git" > README.md
git add README.md

# Фиксируем первый коммит
git commit -m "feat: add README"

# Смотрим историю
git log --oneline
# a1b2c3d feat: add README

# Вносим изменения и смотрим разницу
echo "New line" >> README.md
git diff
# +New line
		

git add . добавляет все изменённые файлы разом, но аккуратнее добавлять конкретные файлы — так вы не затянете в коммит лишнее. Полезный вариант: git add -p — интерактивное добавление по частям (hunks), когда в одном файле несколько логически разных изменений.

Хороший коммит — атомарный: одно логическое изменение, понятное сообщение. Сообщение коммита состоит из заголовка (до 72 символов, отвечает на вопрос «что сделано») и опционального тела (через пустую строку, объясняет «почему»). Плохо: fix. Хорошо: fix: prevent crash when user has no avatar. Привычка писать осмысленные коммиты окупается при поиске багов через git log и git bisect.

Файл .gitignore определяет, какие файлы Git должен игнорировать: зависимости (node_modules/), артефакты сборки (dist/), секреты (.env). Без правильного .gitignore репозиторий быстро засоряется бинарниками и конфигурациями IDE. У нас есть полный гайд по .gitignore с готовыми шаблонами для Python, Node.js и Java. А для быстрой справки — шпаргалки по Git-командам на каждый день.

Команда git diff — главный инструмент для просмотра изменений. Без аргументов она показывает unstaged-изменения рабочей директории. git diff --cached (синоним --staged) — изменения, добавленные в индекс. Сравнение между ветками: git diff main feature/auth. Между конкретными коммитами: git diff a1b2c3d e4f5g6h. Добавьте --stat для краткой сводки по файлам.

Ветвление и слияние

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

			# Создать ветку и переключиться на неё
git switch -c feature/user-auth
# Эквивалент: git checkout -b feature/user-auth

# Посмотреть все ветки
git branch -a

# Переключиться на существующую ветку
git switch main

# Слить feature-ветку в main
git merge feature/user-auth
		

Git выполняет слияние двумя способами. Fast-forward merge происходит, когда целевая ветка является прямым предком исходной — то есть линейная история не расходилась — Git просто перемещает указатель вперёд. 3-way merge (трёхстороннее слияние) используется, когда обе ветки содержат новые коммиты — Git находит общего предка и создаёт merge-коммит с двумя родителями.

Конфликты слияния возникают, когда обе ветки изменили одни и те же строки одного файла. Git помечает конфликтные участки маркерами <<<<<<<, =======, >>>>>>>. Вам нужно выбрать нужную версию (или объединить обе), удалить маркеры и закоммитить результат. Современные IDE вроде VS Code и IntelliJ имеют визуальные инструменты для разрешения конфликтов — используйте их вместо ручного редактирования.

Чтобы минимизировать конфликты, регулярно подтягивайте изменения из основной ветки в свою feature-ветку: git merge main или git rebase main. Чем дольше ветка живёт изолированно, тем больше конфликтов при слиянии. Оптимальная длительность feature-ветки — от нескольких часов до пары дней.

Ненужную ветку удаляют командой git branch -d feature/auth (флаг -D — принудительное удаление, даже если ветка не слита). Переименование — git branch -m old-name new-name. Чтобы обновить remote, удалите старую ветку и запушьте новую: git push origin --delete old-name && git push -u origin new-name.

Для практики ветвления рекомендуем интерактивный тренажёр Learn Git Branching — он визуализирует дерево коммитов и помогает понять, как работают merge, rebase и cherry-pick.

Удалённая работа: remote, push, pull, fetch

Локальный репозиторий — это полная копия проекта, но для командной работы нужен remote — удалённый репозиторий на сервере (GitHub, GitLab, свой сервер). Команда git clone создаёт локальную копию удалённого репозитория и автоматически настраивает remote с именем origin.

			# Клонировать репозиторий
git clone https://github.com/user/project.git

# Посмотреть удалённые репозитории
git remote -v
# origin  https://github.com/user/project.git (fetch)
# origin  https://github.com/user/project.git (push)

# Отправить изменения на сервер
git push origin main

# Получить изменения с сервера
git pull origin main
		

Важно понимать разницу между git pull и git fetch. fetch скачивает новые коммиты с сервера, но не изменяет вашу рабочую ветку — вы можете спокойно посмотреть, что изменилось, через git log origin/main. pull — это fetch + merge в одну команду: скачивает и сразу сливает. Подробный разбор — разница между pull и fetch.

При командной работе вы часто столкнётесь с tracking-ветками. Когда вы делаете git push -u origin feature/auth, флаг -u связывает локальную ветку с удалённой. После этого достаточно писать просто git push и git pull без указания remote и ветки.

Совет: используйте git pull --rebase вместо обычного pull — так вы избежите лишних merge-коммитов при синхронизации с удалённой веткой. Это можно сделать поведением по умолчанию: git config --global pull.rebase true. Подходит не всем командам — если для вас важна полная история ветвлений (например, для аудита), оставьте обычный merge при pull.

Отмена изменений: revert, reset, stash

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

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

			# Отменить последний коммит (создаст новый revert-коммит)
git revert HEAD

# Отменить конкретный коммит
git revert a1b2c3d
		

git reset — откат истории. Перемещает указатель ветки на указанный коммит. Три режима определяют, что происходит с файлами:

• --soft — коммит убирается, но изменения остаются в staging area. Удобно, если хотите переделать коммит.
• --mixed (по умолчанию) — коммит убирается, изменения остаются в рабочей директории, но не в staging.
• --hard — коммит убирается, все изменения удаляются. Осторожно: это необратимо для незакоммиченных правок.

			# Отменить последний коммит, сохранив изменения в staging
git reset --soft HEAD~1

# Убрать файл из staging (не трогая рабочую копию)
git reset HEAD -- file.txt
		

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

			# Спрятать изменения
git stash

# Посмотреть список stash-записей
git stash list

# Вернуть последние спрятанные изменения
git stash pop

# Применить конкретный stash без удаления
git stash apply stash@{1}
		

О detached HEAD стоит знать отдельно. Это состояние, когда HEAD указывает не на ветку, а на конкретный коммит. Любые новые коммиты в этом состоянии не принадлежат ни одной ветке и будут потеряны при переключении. Решение: создайте ветку командой git switch -c branch-name. Ещё больше сценариев разобрано в статье про типичные ошибки и как их исправить, а практические приёмы — в материале про Git-команды для исправления ошибок. Детальное сравнение инструментов отката — reset, revert и checkout на практике.

Rebase, cherry-pick и переписывание истории

git rebase переносит цепочку коммитов на новую базу. Вместо merge-коммита вы получаете линейную историю — как будто ваши изменения были сделаны поверх последней версии основной ветки. Это делает историю чище и проще для чтения.

			# Обновить feature-ветку относительно main
git switch feature/auth
git rebase main

# Interactive rebase: редактировать последние 3 коммита
git rebase -i HEAD~3
# pick a1b2c3d feat: add login form
# squash d4e5f6a fix: typo in login
# pick g7h8i9j feat: add validation
		

Interactive rebase (git rebase -i) — мощный инструмент для «причёсывания» истории перед публикацией. Вы можете склеить несколько коммитов в один (squash), переформулировать сообщения (reword), удалить коммиты (drop) или изменить их порядок.

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

git cherry-pick копирует конкретный коммит из одной ветки в другую. Полезно, когда нужно перенести один багфикс без слияния всей ветки:

			# Перенести один коммит в текущую ветку
git cherry-pick a1b2c3d

# Исправить сообщение последнего коммита
git commit --amend -m "fix: correct validation logic"

# Посмотреть историю всех действий (включая reset, rebase)
git reflog
		

git reflog — «чёрный ящик» Git. Хранит историю перемещений HEAD: 90 дней для достижимых коммитов и 30 дней для недостижимых (после reset или rebase). Даже «потерянный» коммит можно найти через reflog и восстановить — но не тяните дольше месяца. Больше о cherry-pick и других полезных командах — в статье cherry-pick и другие полезные команды. О выборе между rebase и merge — отдельный разбор: когда rebase, а когда merge.

Для массового переписывания истории используют git filter-branch или его современную замену — git filter-repo (устанавливается отдельно через pip install git-filter-repo). Типичные сценарии: удалить случайно закоммиченный пароль, сменить email автора во всех коммитах, вырезать крупный бинарный файл из истории. После переписывания истории потребуется git push --force. Безопаснее использовать git push --force-with-lease — эта команда отвергнет push, если remote-ветка обновилась после вашего последнего fetch, защищая от случайной перезаписи чужих коммитов.

Теги, релизы и версионирование

Теги — это именованные указатели на конкретные коммиты, обычно используемые для маркировки релизов. В Git есть два типа тегов: lightweight (просто указатель, как закладка) и annotated (полноценный объект с автором, датой и сообщением). Для релизов всегда используйте аннотированные теги:

			# Аннотированный тег для релиза
git tag -a v1.2.0 -m "Release 1.2.0: user authentication"

# Lightweight тег (для временных меток)
git tag temp-checkpoint

# Отправить теги на сервер
git push origin --tags

# Посмотреть все теги
git tag -l "v1.*"
		

Стандартная схема версионирования — Semantic Versioning (SemVer): MAJOR.MINOR.PATCH. MAJOR увеличивается при несовместимых изменениях API, MINOR — при новой функциональности с обратной совместимостью, PATCH — при багфиксах. Например, v2.1.3 означает вторую мажорную версию, первое минорное обновление и третий патч.

На GitHub теги автоматически превращаются в Releases — страницы с описанием изменений, бинарными файлами для скачивания и автоматически сгенерированными release notes на основе коммитов. Вы можете привязать к релизу скомпилированные бинарники, архивы, Docker-образы — всё, что нужно пользователям для установки конкретной версии.

Полезная практика — автоматизировать создание релизов. Инструменты вроде semantic-release и release-please анализируют коммиты в формате Conventional Commits и автоматически определяют следующий номер версии, генерируют CHANGELOG и создают GitHub Release. Это убирает человеческий фактор из процесса версионирования.

Переключиться на тег можно командой git checkout v1.2.0 или git switch --detach v1.2.0 — вы окажетесь в состоянии detached HEAD. Чтобы начать работу от тега, создайте ветку: git checkout -b hotfix/v1.2.1 v1.2.0. Ещё одна полезная конвенция — файл CITATION.cff в корне репозитория: GitHub распознаёт его и показывает кнопку «Cite this repository», что важно для научных и open-source-проектов.

Git Hooks: автоматизация проверок

Git hooks — это скрипты, которые Git автоматически запускает при определённых событиях: перед коммитом, после push, при получении изменений. Они позволяют автоматизировать проверки качества кода без настройки CI/CD. Подробный разбор — автоматизация проверок с Git hooks.

Основные клиентские хуки:

• pre-commit — запускается перед коммитом. Типичное использование: линтинг, форматирование, проверка секретов.
• commit-msg — проверяет сообщение коммита. Например, соответствие формату Conventional Commits.
• pre-push — запускается перед push. Можно прогнать тесты, чтобы не отправлять сломанный код.

Серверные хуки (pre-receive, post-receive) выполняются на стороне сервера и контролируют, какие push-запросы принимать. Они используются для enforce-политик: запрет force push в main, обязательные code review и т.д.

Среди менее известных, но полезных хуков: post-checkout — срабатывает после git checkout или git switch и удобен для автоматической переустановки зависимостей при переключении веток (например, npm install если изменился package-lock.json). post-update — серверный хук, выполняется после обновления refs; используется для отправки уведомлений или триггера деплоя.

			#!/bin/sh
# .git/hooks/pre-commit — запрет коммита с TODO
if git diff --cached | grep -q 'TODO'; then
  echo "ERROR: Commit contains TODO markers"
  exit 1
fi
		

Проблема хуков — они хранятся в .git/hooks/ и не попадают в репозиторий. Инструменты вроде Husky (JavaScript), pre-commit (Python) и Lefthook (Go, универсальный) решают эту проблему: хуки описываются в конфигурационном файле, который коммитится в репозиторий, и автоматически устанавливаются при npm install или аналогичной команде.

Продвинутые инструменты

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

git bisect

git bisect — бинарный поиск коммита, сломавшего код. Вы указываете «хороший» и «плохой» коммит, а Git автоматически переключается между ними, сужая диапазон, пока не найдёт виновника. Незаменим, когда баг появился «где-то на прошлой неделе»:

			git bisect start
git bisect bad          # текущий коммит сломан
git bisect good v1.0.0  # эта версия работала
# Git переключается на средний коммит — проверяете, работает ли
git bisect good         # или: git bisect bad
# ...повторяется до нахождения виновника
git bisect reset         # выйти из режима bisect
		

git worktree

git worktree позволяет иметь несколько рабочих директорий одного репозитория одновременно. Вместо git stash + переключения ветки вы можете открыть вторую ветку в отдельной папке и работать параллельно. Без флага -b команда работает только для уже существующей ветки:

			# Создать worktree для существующей ветки
git worktree add ../hotfix-branch hotfix/critical-bug

# Создать worktree с новой веткой (-b)
git worktree add -b hotfix/critical-bug ../hotfix-branch main

# Посмотреть все worktree
git worktree list

# Удалить worktree
git worktree remove ../hotfix-branch
		

git lfs

git lfs (Large File Storage) — расширение для работы с большими файлами (изображения, видео, модели ML). Вместо хранения бинарников в истории Git, LFS заменяет их указателями и хранит сами файлы на отдельном сервере. Без LFS репозиторий с бинарниками быстро разрастается до гигабайтов.

git submodule

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

git blame и .gitattributes

git blame показывает, кто и когда изменил каждую строку файла. Незаменим для понимания контекста изменений — вместо вопроса «кто это написал?» вы сразу видите автора, дату и коммит. В IDE есть встроенные аналоги (Git Lens в VS Code, Annotate в IntelliJ). git format-patch и git apply позволяют экспортировать и импортировать изменения как файлы-патчи — полезно для передачи изменений без доступа к общему remote.

Файл .gitattributes управляет атрибутами путей в репозитории. Главное применение — нормализация переносов строк: строка * text=auto автоматически конвертирует CRLF в LF при коммите — критично для команд, где Windows- и Linux-разработчики работают над одним кодом. Также через .gitattributes отмечают бинарные файлы (*.png binary), выбирают алгоритм diff для конкретных типов (*.py diff=python) и настраивают стратегии merge.

Работа в команде: workflow и best practices

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

Git Flow, GitHub Flow и Trunk-Based

Три основных подхода — Git Flow, GitHub Flow и Trunk-Based Development:

• Git Flow — формальная модель с ветками develop, release, hotfix. Подходит для проектов с чётким циклом релизов (мобильные приложения, десктопный софт).
• GitHub Flow — упрощённый: main + feature-ветки + pull requests. Подходит для web-проектов с непрерывным деплоем.
• Trunk-Based Development — все работают в main, feature-ветки живут максимум 1–2 дня. Требует зрелой культуры CI/CD и feature flags.

Conventional Commits

Conventional Commits — формат сообщений коммитов, который структурирует историю и позволяет автоматически генерировать changelogs. Шаблон: type(scope): description. Основные типы: feat (новая фича), fix (багфикс), docs, refactor, test, chore.

Именование веток — ещё одна важная конвенция. Распространённая схема: type/description, например feature/user-auth, fix/login-crash, chore/update-deps. Если команда использует трекер — добавляйте номер задачи: feat/PROJ-123_user-auth.

Code review через pull requests — обязательная практика. PR (pull request) или MR (merge request в GitLab) — это предложение слить вашу ветку в основную. Коллеги проверяют код, оставляют комментарии, предлагают изменения. Хороший PR: небольшой и фокусированный, с описанием «зачем», скриншотами UI-изменений и ссылкой на задачу в трекере.

Защита веток (branch protection rules) — ещё один уровень безопасности. Можно запретить push напрямую в main, потребовать минимум один approve на PR, обязательное прохождение CI-пайплайна перед merge. Это предотвращает случайные поломки продакшена и формализует процесс доставки кода. Гит интегрируется в контекст DevOps — подробнее об этом в Git в контексте DevOps-инженерии.

Файл CONTRIBUTING.md в корне репозитория описывает правила контрибуции: как форкнуть проект, стиль кода, требования к тестам, оформление PR. GitHub автоматически показывает ссылку на него при создании issue и pull request. Весь текст в GitHub-экосистеме оформляется на Markdown — языке разметки с простым синтаксисом: заголовки, списки, блоки кода, таблицы, task lists (- [x] Готово), @mentions коллег. GitHub Flavored Markdown (GFM) расширяет стандартный Markdown автолинковкой URL, зачёркиванием и таблицами.

Платформы для хостинга Git-репозиториев

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

Облачные платформы

GitHub — крупнейшая платформа для хостинга Git-репозиториев с более чем 100 млн разработчиков. Основные инструменты: Pull Requests для code review, Issues для трекинга задач, Actions для CI/CD, Pages для статических сайтов и Copilot — ИИ-ассистент для написания кода. Регистрация бесплатна, для open-source используется Fork → PR workflow. Подробнее — как оформить профиль на GitHub.

GitLab — DevOps-платформа «всё в одном»: CI/CD, реестр контейнеров, мониторинг, управление проектами, Wiki. Доступна как облако и как self-hosted (Community Edition бесплатна). Особенно популярна в корпоративных окружениях, где нужна вся цепочка разработки в одном месте.

Bitbucket — платформа от Atlassian, тесно интегрированная с Jira и Confluence. Поддерживает Pipelines (CI/CD), Code Insights и branch permissions. Бесплатна для команд до 5 человек. Если команда уже работает в экосистеме Atlassian — Bitbucket будет естественным выбором.

GitVerse (gitverse.ru) — платформа от Сбера: хостинг репозиториев, CI/CD, code review. Подходит для команд, которым важна локальная юрисдикция хранения данных.

GitFlic (gitflic.ru) — Git-хостинг с приватными репозиториями и встроенным CI/CD. Поддерживает стандартный Git-workflow, есть бесплатный тарифный план.

Self-hosted решения

GitLab CE (Community Edition) — бесплатная версия GitLab, которую можно развернуть на собственном сервере, в Yandex Cloud, VK Cloud или любом другом облаке. Полный контроль над данными и инфраструктурой.

Gitea (gitea.com) — лёгкий open-source Git-сервер на Go. Быстрее и проще GitLab, подходит для небольших команд. Занимает минимум ресурсов и разворачивается за минуты.

Codeberg (codeberg.org) — некоммерческий хостинг на базе Gitea. Бесплатный и полностью открытый — подходит для open-source проектов и разработчиков, которые предпочитают некоммерческую инфраструктуру.

GitHub Actions и CI/CD

GitHub Actions — встроенная система CI/CD прямо в репозитории. Workflow описываются в YAML-файлах в директории .github/workflows/ и запускаются автоматически при определённых событиях.

			name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test
		

Ключевые концепции GitHub Actions:

• Triggers — события, запускающие workflow: push, pull_request, schedule (cron), workflow_dispatch (ручной запуск)
• Runners — среда выполнения: GitHub-hosted (ubuntu-latest, windows-latest, macos-latest) или self-hosted для собственных серверов
• Secrets — зашифрованные переменные окружения, доступные через ${{ secrets.API_KEY }}. Хранятся в настройках репозитория
• Артефакты и кеш — сохранение результатов сборки между запусками и кеширование зависимостей для ускорения pipeline

Подробнее о CI/CD и смежных практиках — в нашем roadmap DevOps-инженера.

GitHub Pages, Copilot и другие инструменты

GitHub Pages — бесплатный хостинг статических сайтов прямо из репозитория. Поддерживает Jekyll из коробки, custom domains и автоматический SSL. Для привязки своего домена достаточно создать файл CNAME и настроить DNS.

GitHub Copilot — ИИ-ассистент, который подсказывает код прямо в IDE. Работает в VS Code, JetBrains, Neovim и других редакторах.

Security — набор инструментов для безопасности: Dependabot автоматически обновляет зависимости и предупреждает об уязвимостях, code scanning и secret scanning ищут уязвимости и утёкшие секреты в коде.

GitHub CLI (gh) — работа с GitHub из терминала: создание PR, просмотр Issues, управление Actions. Packages — реестр пакетов (npm, Docker, Maven). Projects — встроенное управление задачами с Kanban-доской и таймлайном.

Git на собеседованиях

Git-вопросы встречаются на собеседованиях на позиции любого уровня — от junior до senior. Не потому что нужно знать все команды наизусть, а потому что Git отражает понимание процессов разработки. Вот типичные вопросы и на что обращают внимание:

• Rebase vs merge — когда что? Ожидают: merge для публичных веток (сохраняет историю), rebase для локальных feature-веток (чистая история). Золотое правило rebase.
• Reset vs revert — в чём разница? Ожидают: revert безопасен (новый коммит), reset переписывает историю. Reset --soft/--mixed/--hard.
• Что такое fast-forward merge? Ожидают: линейное перемещение указателя без merge-коммита, возможно когда ветка «впереди» без расхождений.
• Что такое detached HEAD? Ожидают: HEAD указывает на коммит, а не на ветку. Коммиты будут потеряны без создания ветки.
• Как работает cherry-pick? Ожидают: копирует один коммит в текущую ветку с новым хешем. Сценарии использования.
• Что такое stash и когда его использовать? Ожидают: временное хранилище незакоммиченных изменений. Сценарий — переключение контекста.

На senior-позициях вопросы глубже: как устроен Git изнутри (DAG, объекты: blob, tree, commit, tag), стратегии ветвления для микросервисов, как настроить защиту веток (branch protection rules), как организовать монорепозиторий. Могут попросить нарисовать дерево коммитов после серии операций merge/rebase/cherry-pick.

Как готовиться. Практикуйтесь на реальных проектах — создайте тестовый репозиторий и воспроизведите каждый сценарий: конфликт слияния, interactive rebase, bisect. Отработайте ответы на вопросы вслух — на собеседовании важна не только правильность, но и уверенность.

Куда двигаться дальше

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

Следующие направления для изучения: GitOps — управление инфраструктурой через Git-репозитории (ArgoCD, Flux), когда состояние кластера описано в Git и автоматически синхронизируется; CI/CD — автоматизация сборки, тестирования и деплоя (GitHub Actions, GitLab CI, Jenkins); монорепозитории — управление несколькими проектами в одном репозитории (Nx, Turborepo, Bazel).

Начните с трёх команд (add, commit, push), затем освойте ветвление и merge. Когда почувствуете уверенность — переходите к rebase и hooks. Каждая ссылка в этом путеводителе ведёт на детальный разбор с примерами кода.