Что это решает
Папка с файлами вида «договор_финал_2_правки_итог_вот_этот.docx» — симптом отсутствия истории. Git даёт три вещи: полную запись того, кто, когда и что поменял; возможность вернуть любое прошлое состояние целиком или по одному файлу; и параллельные варианты, которые не мешают друг другу. К этому добавился четвёртый повод: когда правки в файлы вносит ИИ-агент, просмотр изменений перед фиксацией остаётся единственным способом увидеть, что он сделал на самом деле, а не что написал в ответе.
Как устроено
Репозиторий
Репозиторий — обычная папка с проектом плюс скрытый каталог .git внутри неё. Вся история лежит там же, локально. Скопировали папку целиком — скопировали историю. Удалили .git — остались только текущие файлы, история исчезла.
Три места, где живёт файл
Рабочая папка — то, что видно в проводнике. Индекс (staging) — черновик следующего коммита. История — зафиксированные снимки. Команда git add перекладывает изменения из рабочей папки в индекс, git commit превращает индекс в новую точку истории. Промежуточный слой существует ровно затем, чтобы можно было зафиксировать три файла из десяти изменённых.
Коммит
Коммит — снимок всех отслеживаемых файлов на момент фиксации, плюс автор, время, сообщение и ссылка на предыдущий коммит. Цепочка этих ссылок и есть история. Опознаётся коммит по длинному хешу, из которого в повседневной работе хватает первых семи символов. Сообщение пишется для того, кто откроет историю через полгода: «Поправил» и «Правки» бесполезны, «Обновил условия оплаты в договоре аренды» — работает.
Ветка
Ветка — подвижный указатель на коммит, ничего больше. Создание ветки не копирует файлы и стоит доли секунды. Основная обычно называется main или master. Работа над отдельным изменением ведётся в своей ветке, чтобы основная всегда оставалась в рабочем состоянии.
Удалённый репозиторий
Копия на сервере — GitHub, GitLab, свой. Локальный репозиторий знает её под коротким именем origin. push отправляет свои коммиты туда, fetch забирает чужие, pull забирает и сразу вливает в текущую ветку.
Слияние и конфликт
Если две ветки правили разные файлы или разные участки одного файла, git сливает их сам. Если обе правили один и тот же участок, возникает конфликт: git вставляет в файл маркеры <<<<<<<, =======, >>>>>>> с обеими версиями и останавливается. Человек оставляет нужное, убирает маркеры, добавляет файл в индекс и завершает слияние. Автоматически такое не решается, потому что выбор смысловой.
Что не отслеживать
Файл .gitignore перечисляет то, что не должно попадать в историю: временные файлы, каталоги зависимостей, выгрузки, файлы с паролями и ключами. Записывается по шаблонам, по одному на строку.
Минимальный набор команд
| Команда | Что делает |
|---|---|
git clone <адрес> | Забрать существующий репозиторий на свою машину |
git status | Что изменено, что в индексе, на какой ветке |
git diff | Показать изменения, которые ещё не в индексе |
git add . | Положить все изменения в индекс |
git commit -m "текст" | Зафиксировать индекс новым коммитом |
git log --oneline | История списком, по строке на коммит |
git switch -c имя | Создать ветку и перейти в неё |
git switch main | Вернуться в основную ветку |
git pull | Забрать и влить изменения с сервера |
git push | Отправить свои коммиты на сервер |
git restore <файл> | Вернуть файл к последнему зафиксированному состоянию |
git revert <хеш> | Новым коммитом отменить действие указанного |
git stash | Временно убрать незафиксированные правки в сторону |
Графические клиенты
GitHub Desktop, Fork, Sourcetree и встроенная панель контроля версий в VS Code закрывают повседневный набор: посмотреть изменения, отметить нужные файлы, зафиксировать, переключить ветку, разрешить конфликт в трёхпанельном редакторе. Термины там те же, поэтому механику всё равно приходится понимать, но набирать команды не обязательно.
Полезные сценарии
- Версии текстов и документации в markdown: видно построчно, что поменялось между редакциями, и кто это сделал.
- Просмотр правок ИИ-агента:
git diffперед фиксацией показывает каждую строку, которую он тронул, включая те, о которых не отчитался. - Откат неудачного изменения:
git revertотменяет конкретный коммит, оставляя историю честной, без затирания. - Конфиги, скрипты и шаблоны автоматизации: любая правка обратима, а не «работало вчера, теперь нет».
- Параллельные варианты: ветка на каждый вариант текста лендинга, сравнение и слияние выигравшего.
- Синхронизация базы знаний между компьютерами с историей вместо облачной перезаписи.
Ограничения
Бинарные файлы git хранит целиком на каждую версию. Docx, xlsx, psd, видео: изменения нечитаемы, слияние невозможно, репозиторий пухнет. Для таких файлов используют Git LFS либо оставляют их в файловом хранилище, а в репозитории держат текстовые исходники.
Репозиторий на том же диске резервной копией не работает. Копия появляется только после отправки на удалённый сервер или на второй носитель.
Секрет, попавший в коммит, остаётся в истории даже после удаления из файла: старый коммит никуда не делся. Вычистить его — переписать историю, и всё равно ключ считается скомпрометированным и подлежит замене.
git push --force затирает на сервере то, чего нет локально, вместе с чужой работой. Для общих веток эта команда закрыта настройками платформы, и правильно, что закрыта.
Конфликты требуют понимания содержания файла. Никакая кнопка не решит, чья формулировка договора правильная.
Git не трекер задач и не согласование. Обсуждения, ревью и статусы живут на платформе поверх него, и переезд на другую платформу их не переносит.
Полный набор возможностей велик: перебазирование, перенос отдельных коммитов, отсоединённое состояние. Без них работается годами, но однажды кто-то произнесёт эти слова, и придётся разбираться.
Как проверить результат
git status после работы: «nothing to commit, working tree clean» означает, что незафиксированного не осталось. Список неотслеживаемых файлов в выводе — повод дописать .gitignore или добавить забытое.
git log --oneline -10: прочитать последние десять сообщений и честно ответить, понятно ли из них, что происходило. Если нет — история есть, пользы от неё нет.
git show HEAD --stat: какие файлы уехали в последний коммит и на сколько строк. Внезапный каталог зависимостей или файл выгрузки в этом списке ловится сразу.
git diff до добавления в индекс и git diff --staged после — привычка читать изменения перед фиксацией. Особенно когда файлы правил агент.
git check-ignore -v <путь>: показывает, какое правило игнорирует файл. Отвечает на вопрос «почему мой файл не добавляется».
Проверка, что копия существует: git remote -v покажет адрес сервера, а клонирование в пустую временную папку и открытие файлов покажет, что копия рабочая, а не что кнопка нажималась.
Учебный откат: испортить файл, выполнить git restore и убедиться, что содержимое вернулось. Один раз сделать это спокойно лучше, чем разбираться в момент аварии.
Поиск секретов перед открытием репозитория наружу: git log -p -S "TOKEN" ищет по всей истории коммиты, где строка появлялась или исчезала.