Что такое Git — Git: Основы

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

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

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

Для DevOps Git особенно важен, потому что в нём обычно живут:

Dockerfile и docker-compose файлы;
Kubernetes manifests и Helm charts;
Terraform и Ansible код;
CI/CD pipeline конфигурация;
скрипты деплоя, миграций и диагностики;
документация по инфраструктуре.

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

Git хранит историю проекта

Обычная папка хранит только текущее состояние файлов. Git-репозиторий хранит ещё и историю состояний.

обычная папка:
README.md
app.py

git-репозиторий:
README.md
app.py
.git/        <- вся история, ветки, настройки и служебные данные Git

После git init внутри проекта появляется скрытая директория .git/. Это и есть локальная база данных Git. Если удалить .git/, файлы останутся на диске, но папка перестанет быть репозиторием: исчезнет история, ветки и связь с remote.

Коммит как точка истории

Коммит - это зафиксированный снимок проекта в конкретный момент. У коммита есть:

хеш, например a1b2c3d;
автор и email;
дата;
сообщение;
ссылка на предыдущий коммит;
снимок содержимого файлов.

История выглядит как цепочка:

A -- B -- C

A, B, C - коммиты. Каждый новый коммит знает своего родителя, поэтому Git может восстановить историю, показать разницу между версиями и понять, какие изменения уже есть в ветке.

Хеш коммита - это не просто номер. Он вычисляется из содержимого и метаданных. Поэтому Git хорошо замечает, если история поменялась.

Три зоны Git

Понимание трёх зон - ключ к пониманию Git:

Рабочая директория   ->   Staging area (индекс)   ->   Репозиторий
  working tree              git add                       git commit

Зона	Что это	Команда
Working tree	Файлы на диске, которые ты редактируешь	редактор, `echo`, `mv`, `rm`
Staging area / index	Изменения, подготовленные для следующего коммита	`git add`
Repository	История коммитов в `.git/`	`git commit`, `git log`

Staging нужен не для усложнения, а для контроля. Ты можешь изменить 10 файлов, но включить в ближайший коммит только 2. Остальные изменения останутся в рабочей директории и пойдут в другой коммит.

Так получаются атомарные коммиты: один коммит - одна логическая мысль.

Snapshot model, не просто дельты

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

Почему это важно:

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

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

Установка и первоначальная настройка

Проверить, установлен ли Git:

git --version

Настроить имя и email автора коммитов:

git config --global user.name "Student"
git config --global user.email "student@example.com"

Посмотреть настройки:

git config --list

Глобальные настройки записываются в ~/.gitconfig и используются во всех репозиториях пользователя. Внутри конкретного проекта можно задать локальные настройки без --global:

git config user.name "Project Bot"
git config user.email "bot@example.com"

Локальные настройки лежат в .git/config и имеют приоритет над глобальными.

Первый репозиторий

Создать новый репозиторий можно двумя способами:

git init /root/project

или:

mkdir -p /root/project
cd /root/project
git init

После этого проверь состояние:

git status

git status - команда, которую нужно запускать постоянно. Она показывает текущую ветку, незакоммиченные изменения, staged-файлы, untracked-файлы и подсказки, что делать дальше.

Короткий формат удобен для быстрой проверки:

git status -s

Если вывод пустой, рабочее дерево чистое.

Первый коммит

Создадим файл и зафиксируем его:

echo "# My Project" > README.md
git status
git add README.md
git status
git commit -m "init"
git log --oneline

Разбор:

echo "# My Project" > README.md создаёт файл;
git status показывает, что файл untracked;
git add README.md добавляет изменение в staging;
git commit -m "init" создаёт коммит;
git log --oneline показывает краткую историю.

Сообщение коммита должно помогать читать историю. Плохие сообщения:

git commit -m "fix"
git commit -m "changes"
git commit -m "wip"

Лучше:

git commit -m "Add deployment script"
git commit -m "Fix nginx config path"
git commit -m "Document rollback procedure"

git log: первая навигация по истории

Обычный лог:

git log

Краткий лог:

git log --oneline

Граф истории:

git log --oneline --graph --all

Пока веток мало, граф выглядит просто. Позже, когда появятся feature-ветки и merge-коммиты, --graph --all станет главным способом понять структуру истории.

Вывод можно сохранить в файл:

git log --oneline > /root/gitlog.txt

Ключевые команды

Команда	Что делает
`git init`	Инициализировать репозиторий
`git status`	Показать текущее состояние
`git status -s`	Короткий статус
`git add <file>`	Добавить файл в staging
`git add .`	Добавить изменения из текущей директории
`git add -p`	Интерактивно выбрать части изменений
`git commit -m "msg"`	Создать коммит
`git log --oneline`	Краткая история
`git log --oneline --graph --all`	Граф всех веток

Главная привычка на старте: перед commit всегда выполнять git status, а если есть изменения - ещё и git diff. Это снижает риск случайно закоммитить лишнее.