Git — система контроля версий: она запоминает историю изменений кода и позволяет нескольким людям работать над одним проектом, не затирая друг друга. Сегодня это не «один из инструментов», а среда обитания: код живёт в Git, задачи закрываются через Git, код-ревью происходит в Git. Ни в одну команду — бэкенд, фронтенд, тестирование — нельзя войти без него.
Проблема, которую он решает
Без контроля версий история проекта выглядит как проект_финал_2_испр_НОВЫЙ.zip. Вопросы без ответов: что изменилось со вчера? кто и зачем поменял эту строку? как откатить неудачную правку, не потеряв удачные? как двум людям править один файл?
Git отвечает на все: каждое сохранённое состояние подписано автором, датой и пояснением; любое можно посмотреть, сравнить и вернуть; параллельная работа — штатный режим, а не катастрофа.
Снимки, а не различия
Ключевая ментальная модель: Git хранит снимки (snapshots) всего проекта. Каждый коммит — это «сфотографированное» состояние всех файлов плюс ссылка на предыдущий снимок. История — цепочка снимков, по которой можно ходить как по ленте времени.
Из этого следует важное: коммит — дёшев и мгновенен, потому что неизменённые файлы не копируются, а переиспользуются. Коммитить часто — нормально и правильно.
Три состояния файла
Файл в Git-проекте живёт в одном из трёх мест:
- Рабочая директория (working directory) — обычные файлы, которые вы редактируете.
- Индекс (staging area) — «предбанник» коммита: сюда вы явно складываете то, что войдёт в следующий снимок.
- Репозиторий — сохранённые коммиты.
git status # что изменено и что в индексе
git add file.txt # положить файл в индекс
git commit -m "пояснение" # сделать снимок из индекса
Индекс поначалу кажется лишним шагом («почему не коммитить сразу всё?»), но это инструмент точности: из десяти изменённых файлов вы можете собрать коммит только из трёх относящихся к задаче — история остаётся осмысленной.
Локальный и удалённый
Git — распределённая система: полная копия истории лежит у вас на машине. Коммиты, ветки, просмотр истории — всё работает локально, без сети. Удалённый репозиторий (на GitHub, GitLab, Bitbucket) — это точка синхронизации команды: туда вы отправляете свои коммиты (push) и оттуда забираете чужие (pull).
git clone https://github.com/team/project.git # скопировать проект себе
git pull # забрать новое с сервера
git push # отправить свои коммиты на сервер
Отсюда два практических следствия. Первое: «закоммитил» ещё не значит «отправил» — коллеги увидят вашу работу только после push. Второе: у каждого разработчика есть полный бэкап истории — потерять проект целиком практически невозможно.
Где это помогает бэкендеру
Git — это не только «сдать код». История — инструмент отладки: «когда сломалось?» решается просмотром недавних коммитов, «кто и зачем написал эту строку» — командой git blame, «воспроизвести баг версии 2.3» — переключением на тег этой версии. А вся автоматика доставки — CI/CD-конвейер — запускается именно от событий в Git: push в ветку собирает и тестирует код, слияние в главную — деплоит.
Коротко
- Git хранит историю как цепочку снимков-коммитов; коммит дёшев — коммитьте часто.
- Три состояния: рабочая директория → индекс (
git add) → репозиторий (git commit). Индекс позволяет собирать точные коммиты. - Система распределённая: всё локально, сервер — точка синхронизации. Коммит ≠ push.
git status— ваш компас: всегда показывает, где вы и что изменено.
Что почитать дальше
- Коммиты и история — как делать хорошие коммиты и читать историю.
- Ветки и слияние — главный механизм параллельной работы.
- Команды Linux-терминала — если терминал сам по себе ещё непривычен.