1.1 Что такое Git? Ваше первое знакомство

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

Проблема, которую решает Git

Представьте ситуацию: вы работаете над проектом — пишете код, создаёте файлы, вносите изменения. Через неделю понимаете, что ваша последняя версия работала лучше, чем текущая. Или вам нужно вернуться к коду, который вы написали месяц назад. Как быть?

Без системы контроля версий вы:

Создаёте копии файлов вручную: project_v1.txt, project_v2.txt, project_FINAL.txt
Теряетесь в версиях и не помните, что именно изменилось
Не можете работать в команде — изменения конфликтуют
Боитесь что-то сломать, потому что нет возможности откатиться

Git решает все эти проблемы. Он автоматически сохраняет историю всех изменений, позволяет откатываться к любой версии, работать в команде и не бояться экспериментов.

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

VCS (Version Control System, система контроля версий) — это инструмент, который:

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

Что такое Git?

Git — это самая популярная система контроля версий в мире. Он был создан в 2005 году Линусом Торвальдсом (создателем Linux) для управления разработкой ядра Linux и с тех пор стал стандартом индустрии.

Git — это распределённая система контроля версий. Что это значит?

Централизованная vs Распределённая VCS

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

Благодаря распределённой модели:

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

Что вы освоите в этом модуле

Понять зачем нужен Git: решаемые проблемы, преимущества
Освоить ключевые понятия: репозиторий, коммит, хеш, ветки
Понять три состояния файлов: modified → staged → committed
Изучить архитектуру Git: рабочая директория, индекс, база данных
Сделать первые коммиты: установка, настройка, базовые команды
Понять как Git хранит данные: снимки (snapshots) вместо патчей

Главная цель модуля

Наша главная цель — не просто выучить команды, а понять, как Git «думает» о данных. Если вы уловите общую картину, отдельные команды станут логичными и понятными.

Мы разберём:

Почему Git работает со снимками (snapshots), а не с патчами
Чем обусловлены три состояния файлов
Как из объектов складывается граф истории
Почему Git такой быстрый и надёжный

Практические советы для начинающих

Не пытайтесь выучить все команды сразу — начните с базовых
Экспериментируйте! Git прощает ошибки, почти всё можно исправить
Используйте git status постоянно — он покажет текущее состояние
Пишите понятные сообщения к коммитам — вы будете благодарны себе позже
Делайте маленькие коммиты — так проще понять, что изменилось

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

Системы контроля версий существуют давно, но подходы менялись:

CVS, Subversion (1990-2000-е) — централизованные системы. Медленное ветвление и слияние, зависимость от сервера
Mercurial, Git (2005) — распределённые системы. Быстрые операции, локальная история, независимость от сервера

Интересный факт: Git создан Линусом Торвальдсом в 2005 году для разработки Linux‑ядра. За несколько месяцев он стал настолько популярным, что сегодня используется практически во всех проектах разработки программного обеспечения.

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

1.2 Почему Git?

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

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

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

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

Модель данных Git (упрощённо)

Коммит → указывает на дерево (root) + на родителя(ей)
Дерево → указывает на другие деревья/блоки (файлы)
Блоб → содержимое файла (контент)

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

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

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

Советы

Используйте git add -p, чтобы собирать «чистые» коммиты по смыслу
Хорошие сообщения повышают качество ревью и ускоряют поиск ошибок

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

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

Полезные настройки

git config --global core.autocrlf true (Windows) — управление переводами строк
git config --global pull.rebase false|true — стратегия pull
git config --global init.defaultBranch main — название основной ветки

На старте уделите время настройке: имя/почта, стратегия 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 практичным стандартом индустрии.

Git