Блок 1. Урок 1: Git и «три зоны»

Урок 1. Git: что это и «три зоны»

Зачем это тебе

Каждый день ты раскатываешь деплои: код забирается из репозитория (Bitbucket), Jenkins собирает и выкатывает его на системы. Репозиторий — «дом» кода, которым управляет git. Первый шаг любого деплоя — «взять код из git», поэтому понимать механику git — инструмент диагностики при упавших деплоях и откатах.

Что такое система контроля версий

Система контроля версий — программа, которая хранит файлы вместе с историей изменений и позволяет вернуться к любой сохранённой точке.

Репозиторий (repo) — папка проекта со скрытой папкой .git, в которой живёт история. Бывает двух видов:

• Локальный — на твоей машине, в папке .git внутри проекта; это твоя работа и твоя история.

• Удалённый — общий «сейф» на сервере (у вас — Bitbucket), откуда Jenkins забирает код для сборки и деплоя.

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

Три зоны git

• Рабочая копия — файлы, которые ты видишь и правишь в редакторе.

• Индекс (staging) — «отобранное»: что уйдёт в следующий коммит.

• История коммитов — готовые контрольные точки (локальный репозиторий).

Движение файла всегда одинаковое:

Рабочая копия  --(git add)-->  Индекс  --(git commit)-->  История (локально)

Команды работают так:

• git init — создаёт репозиторий в текущей папке (появляется скрытая .git).

• git status — главная команда-помощник: состояние всех трёх зон.

• git add <файл> — рабочая копия → индекс. git add . — добавить все изменения.

• git commit -m "Сообщение" — индекс → история (локально).

• git log --oneline — краткая история: хеш + сообщение коммита.

• git diff — изменения в рабочей копии, которые ещё не попали в индекс.

• git restore --staged <файл> — убрать файл из индекса обратно в рабочую копию.

• git push — отправить локальные коммиты в удалённый репозиторий.

Ключевой нюанс: после git commit изменения живут только в твоём локальном репозитории. Запомни: «commit — это локально, push — это на сервер».

Сквозной пример

mkdir lesson1 && cd lesson1
git init                     # Initialized empty Git repository...
echo "Привет, git" > hello.txt
git status                   # Untracked files: hello.txt
git add hello.txt
git status                   # Changes to be committed: new file
git commit -m "Добавил hello.txt"   # 1 file changed
git log --oneline            # a1b2c3d Добавил hello.txt

Теперь измени hello.txt, посмотри git diff, снова выполни git add + git commit — и в git log --oneline будет уже 2 коммита.

Типичные ошибки

• Коммит ≠ отправка на сервер. Без push твои коммиты видишь только ты.

• Сообщения коммитов. «Исправил NPE в OrderService» лучше, чем «правки правки».

• Секреты. Никогда не коммить токены, пароли и ключи — они навсегда остаются в истории.

• Мусор. Логи и артефакты сборки — в .gitignore, чтобы не попадали в коммиты случайно:

*.log
secret/
*.tmp

• git add . — с осторожностью: сначала git status, потом решай, что добавлять.

Итог

Git хранит файлы вместе с историей изменений. Файл движется по трём зонам: рабочая копия → git add → индекс → git commit → история. Коммит — локальная контрольная точка; на удалённый репозиторий изменения уходят командой git push.

Источники

Учебный план «Блок 1. Инструменты, которые трогаешь каждый день» (урок 1), составлен для курса автором.