Зачем Git, если можно копировать папки?

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

Почему ручное копирование папок ненадёжно

Возьмём реальную картину: папка с проектом, и в ней три файла — README_1.md, README_2.md, README_final.md. Через месяц добавляется README_final2.md. Что именно в каждом из них? Когда сделана последняя правка? Зачем? Ответить на эти вопросы, глядя только на имена, невозможно.

Здесь ломается не один, а сразу четыре механизма.

Имена ничего не говорят. README_v2 и README_new — одинаково бессмысленные метки. «final» и «final2» не несут никакого содержания: непонятно, что изменилось и почему.

Причина правки нигде не зафиксирована. В файловой системе нет поля «зачем». Если вы исправили опечатку, убрали устаревший раздел или поменяли контактный e-mail — спустя неделю об этом не останется никакого следа, кроме самого файла.

Удалённое не вернуть без ручного сравнения. Допустим, в README_2.md был контактный e-mail, а в README_final.md его нет. Чтобы понять, куда он делся и каким он был, нужно открыть оба файла и сравнивать построчно. Если файлов пять — сравниваешь пять пар.

При совместной работе возникают конфликтующие копии. Один человек правит README_final.md и сохраняет как README_final_Anya.md. Другой делает то же самое — README_final_Ivan.md. Теперь есть два «финальных» файла с разными правками, и непонятно, как их объединить без ручной склейки.

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

Git как цепочка снимков проекта

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

Вместе со снимком Git сохраняет:

• метку времени — когда именно;
• сведения об авторе из настроек Git — кто зафиксировал;
• описание, которое пишет сам автор, — что изменилось и зачем.

Git не сочиняет причину правки. Полезное описание появляется в истории, когда человек осмысленно формулирует его при фиксации.

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

Вернёмся к сценарию с тремя файлами README. Вместо трёх отдельных копий история в Git выглядит примерно так:

Снимок 1 — «Первая версия README»
  автор: Аня  |  дата: 1 мая  |  файл: README.md

Снимок 2 — «Добавлен раздел Установка»
  автор: Аня  |  дата: 3 мая  |  файл: README.md

Снимок 3 — «Добавлен раздел Авторы, убран контактный e-mail»
  автор: Иван  |  дата: 7 мая  |  файл: README.md

Чтобы найти удалённый e-mail, не нужно открывать файлы и сравнивать вручную. Достаточно посмотреть на снимок 2: там e-mail ещё есть. Git знает разницу между снимком 2 и снимком 3 — именно в ней и находится удалённая строка.

Каждый из четырёх отказов ручного копирования закрывается напрямую:

• Имена файлов больше не нужны как метки версий — роль метки берёт описание снимка.
• Причина правки записана в описании — её задаёт сам автор.
• Удалённую строку можно найти, сравнив два соседних снимка — Git это делает автоматически.
• Два человека работают с одним файлом README.md, а не плодят README_Anya.md и README_Ivan.md — история у каждого своя, и Git умеет объединять цепочки снимков.

Вы продолжаете редактировать один README.md под прежним именем, а сохранённые версии Git хранит в истории. Обычная правка меняет текущий файл, но не переключает снимок и не меняет уже записанную историю. Например, после снимка 3 вы можете исправить опечатку в README.md: исправление уже есть в рабочем файле, но в истории его ещё нет. Просмотр или восстановление прежней версии — отдельное действие.

Git ≠ GitHub: локальная история без облака

Git и GitHub — разные продукты. Их часто путают, потому что слова похожи и их нередко упоминают вместе. Но они решают разные задачи.

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

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

Простая аналогия: Git — это дневник, который лежит у вас дома. GitHub — это сервис, который позволяет хранить копию дневника в облаке и показывать отдельные страницы другим людям. Дневник существует и без облака. Облако без дневника — просто пустое хранилище.

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