Git для одного: история правок сайта, статьи и файлов

Git нужен не только разработчикам в худи и командам из двадцати человек. Если вы один собираете лендинг, пишете статью в Markdown или правите презентацию, он заменяет папки вроде `сайт_финал`, `сайт_финал2` и `сайт_финал_точно_7`.

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

История версий файлов сайта в интерфейсе Git

Git полезен там, где важен текст

Лучше всего Git работает с текстовыми файлами: HTML, CSS, JavaScript, Markdown, CSV и настройками. Команда `git diff` покажет изменения построчно. Удалили сильный абзац из статьи или случайно стёрли блок с формой — это будет видно до сохранения.

Представьте: утром вы переписали первый экран лендинга `coffee-landing`, а вечером поняли, что прежний заголовок был живее. Git позволит вернуть только `index.html`. Новые стили и форма заявки останутся нетронутыми.

Картинки, видео, `.docx` и `.pptx` тоже можно складывать в Git. Но для них это скорее архив версий: вернуть вчерашний файл получится, а увидеть замену двух слов на третьем слайде — обычно нет. Для статьи в Google Docs Git сам ничего не синхронизирует: документ придётся экспортировать в рабочую папку.

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

Одна папка — одна понятная история

Установите Git и проверьте, что терминал его видит:

git --version

Откройте терминал в папке проекта. В примере это лендинг кофейни. Команда ниже создаст в папке скрытую директорию `.git` — там Git хранит историю.

cd путь/к/coffee-landing
git init

Задайте имя и почту для коммитов только в этой папке. Это подпись автора изменений, а не регистрация где-либо.

git config user.name "Женя"
git config user.email "zhenya@example.com"

До первого коммита создайте файл `.gitignore`. В него попадают секреты, временные файлы и тяжёлые служебные папки, которые не нужны в истории.

.env
.DS_Store
node_modules/

В `.env` часто лежат ключи доступа. Если файл уже попал в коммит, добавление в `.gitignore` не сотрёт старую версию из истории. Сразу замените засвеченный ключ: считать его секретным уже поздно.

Первый коммит — ваша точка возврата

Сначала посмотрите, какие файлы заметил Git:

git status

Проверьте список. Если там нет секретов и мусора, добавьте файлы в будущую точку сохранения:

git add .

Теперь создайте первый коммит:

git commit -m "Сохранил исходную версию лендинга"

Коммит — не «финал». Это сохранение в игре с нормальной подписью. Пишите, что сделали: «Сократил лид статьи», «Добавил блок с тарифами», «Вернул короткий заголовок». Сообщения `update`, `fix` и `final_final` через месяц не объяснят вообще ничего.

Если в папке лежит что-то сомнительное, не используйте `git add .`. Добавьте конкретный файл и сразу сохраните его:

git add index.html
git commit -m "Переписал первый экран"

Терминал с командами Git для сохранения изменений

Четыре команды на обычный рабочий день

После заметной правки сначала смотрите разницу:

git diff

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

Если правки нормальные, подготовьте их:

git add .

Перед сохранением проверьте будущий коммит:

git diff --staged

И только потом зафиксируйте версию:

git commit -m "Обновил оффер и кнопку на первом экране"

В одиночной работе обычно хватает `git status`, `git diff`, `git add` и `git commit`. Не нужен курс на сорок уроков, где полчаса объясняют, как открыть терминал. Сделайте пять коммитов в живом проекте — и нужные фичи начнут находиться сами.

Три аварии, когда Git спасает день

Испортили файл до коммита

Вы заменили хороший лид статьи скучным нейросетевым киселём. Сначала посмотрите изменения:

git diff article.md

Если файл ещё не добавляли через `git add`, верните его к состоянию последнего коммита:

git restore article.md

Команда сотрёт текущие изменения только в `article.md`. Сначала `diff`, потом `restore`, не наоборот. Детали поведения команды есть в официальной справке Git.

Неудачная правка уже сохранена

Посмотрите короткую историю:

git log --oneline

Допустим, неудачный редизайн имеет идентификатор `a1b2c3d`. Отмените его отдельным новым коммитом:

git revert a1b2c3d

`git revert` не переписывает прошлое, а создаёт обратное изменение. Это удобный вариант, если вы уже отправили проект в удалённое хранилище.

Нужен один файл из старой версии

Хотите оставить новые стили, но вернуть старый текст первого экрана? Возьмите `index.html` из нужного коммита:

git restore --source=a1b2c3d -- index.html
git add index.html
git commit -m "Вернул прежний текст первого экрана"

Остальные файлы Git не тронет. Ради таких точечных откатов его стоит завести даже для одной статьи или лендинга.

GitHub — второй сейф, а не сам Git

Git хранит историю на вашем компьютере. GitHub, GitLab и похожие сервисы держат копию проекта в интернете. Это защита от сломанного ноутбука, потерянного диска и кофе, который решил познакомиться с клавиатурой.

Сначала привыкните к локальным коммитам. Затем создайте пустой удалённый репозиторий и привяжите его к папке:

git remote add origin REMOTE-URL
git remote -v

Узнайте имя текущей ветки:

git branch --show-current

Если увидели `main`, отправьте историю:

git push -u origin main

Если команда вывела другое имя, подставьте его вместо `main`. У GitHub есть пошаговая инструкция по подключению удалённого репозитория.

Сегодня выберите одну рабочую папку, выполните `git init` и сделайте коммит с человеческим названием. В следующий раз удачный заголовок будет лежать в истории проекта, а не прятаться в `финал_точно_7`.

Статья помогла?