Git — Основы

1.1 Что такое система контроля версий (VCS)?

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

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

Короткая история VCS

• CVS/Subversion — централизованные, медленнее ветвление и слияние
• Mercurial/Git — распределённые, быстрые операции, локальная история

1.2 Почему Git?

• Скорость и офлайн: коммиты/лог/дифф — локально, мгновенно
• Ветвление/слияние: дешёвые операции, богатые сценарии
• Надёжность: объекты по хешам, контроль целостности

Практически все современные процессы разработки (code review, CI/CD, feature‑ветки) выросли на возможностях Git. Он поощряет короткоживущие ветки, частые коммиты и чёткую историю, что ускоряет интеграцию изменений и снижает риски релизов.

1.3 Ключевые понятия

• Репозиторий: папка проекта + каталог .git с историей
• Коммит: снимок состояния проекта + метаданные (автор, дата, сообщение)
• Хеш (SHA‑1): уникальный идентификатор коммита/объекта
• Дерево и блоб: каталоги и содержимое файлов в базе Git

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

1.4 Три состояния файла

• modified — изменён в рабочей директории
• staged — добавлен в индекс (staging)
• committed — сохранён в истории (в базе Git)

Индекс — это сознательный отбор изменений в будущий коммит. Разделяйте независимые правки по разным коммитам: история станет понятнее, а откаты — безопаснее.

1.5 Базовая архитектура Git

Поток данных: Working Directory → Index (Staging) → Git Database (.git).

• Working Directory — редактируете файлы
• Index — собираете будущий коммит
• .git — база объектов истории (коммиты, деревья, блобы)

Эти три «слоя» образуют основу всех операций. Команды Git, по сути, двигают данные между рабочей директорией, индексом и базой объектов, меняя лишь то, что вы явно указали.

1.6 Практика: первые шаги

# Установка и конфигурация
# Windows: https://git-scm.com/download/win, macOS: brew install git, Linux: apt/yum/pacman

git --version

git config --global user.name "Ваше Имя"
git config --global user.email "you@example.com"
# Опционально задайте ветку по умолчанию
git config --global init.defaultBranch main

# Создание репозитория и базовые команды
mkdir my-project && cd my-project
git init

echo "Hello" > README.md

git status           # состояние

git diff             # изменения в рабочих файлах (до add)

git add README.md    # добавить файл в staging
# или добавить все изменения:
# git add .

git commit -m "feat: add README"

git log --oneline --graph --decorate

На старте уделите время настройке: имя/почта, стратегия pull, правила перевода строк. Это избавит от множества мелких проблем и приведёт к предсказуемому поведению на всех машинах.

1.7 Объектная модель Git: blob, tree, commit, tag

Git хранит данные как контент‑адресуемые объекты в каталоге .git/objects. Базовые типы: blob (содержимое файла), tree (каталог: имена, режимы, ссылки на объекты), commit (метаданные + ссылка на корневое дерево и родителей), tag (подписанная ссылка на объект).

Коммит указывает на дерево и на родителя(ей), формируя DAG (ориентированный ациклический граф) истории. Идентификаторы — хеши от содержимого и заголовка объекта.

Контент‑адресуемость означает, что объект определяется своим содержимым. Если содержимое совпадает — хеш совпадает, а значит, объекты переиспользуются. Это делает Git экономным и надёжным.

1.8 Хеширование: от SHA‑1 к SHA‑256

Изначально Git использует SHA‑1 для адресации объектов. Из‑за уязвимостей введён режим SHA‑256. Переход требует согласованности на уровне репозитория и инструментов. Основная идея неизменна: хеш = адрес объекта, что гарантирует целостность.

Для большинства повседневных сценариев выбор алгоритма прозрачен. Важно понимать сам принцип: неизменяемое содержимое → стабильный идентификатор → проверяемая целостность по всей истории.

1.9 Porcelain vs Plumbing

Porcelain — «пользовательские» команды (git switch, git commit). Plumbing — низкоуровневые команды (git hash-object, git cat-file), раскрывающие внутренности. Понимание plumbing помогает глубже разбираться в поведении Git.

Иногда, столкнувшись с нетривиальной ситуацией, полезно «нырнуть» на уровень plumbing, чтобы увидеть, какие объекты и ссылки действительно создаются и куда они указывают.

1.10 Индекс (staging) в деталях

Индекс — это «макет» следующего коммита. Он хранит тройки (путь, режим, хеш объекта). Частичные добавления (add -p) формируют осмысленные коммиты. Конфликты представляются несколькими записями на один путь (stage 1/2/3).

Мыслите индексом как «списком намерений»: вы явно решаете, что войдёт в снимок. Это дисциплинирует и помогает строить линейную, понятную историю.

1.11 Снимки против диффов

Git мыслит снимками состояний, а не патчами. Диффы вычисляются на лету при сравнении снимков. Такой подход ускоряет операции, упрощает ветвление и повышает надёжность хранения.

Это — фундаментальное отличие от многих старых VCS. Снимки упрощают ветвление, слияние и повторное использование данных, что и делает Git практичным стандартом индустрии.