Этап 3 - Эффективное отслеживание изменений

К концу второго этапа у task-service уже есть несколько commits. Теперь важно научиться контролировать, что именно готово к следующему commit, чтобы не смешивать разные идеи.

Почему просмотр diff — это не формальность

Если вы сразу коммитите всё подряд, история быстро превращается в «случайную правду». Допустим, вы меняете task-service.js, чтобы убрать дубликаты задач, и одновременно поправляете README.md. Без проверки diff вы не уверены, что именно отправили в историю.

Сначала проверьте статус:

git status

git diff покажет изменения в рабочей директории, а не в staging:

git diff

Если вы уже добавили task-service.js в staging, то staged-изменения видны через:

git diff --staged

Это помогает избегать смешивания: исправление поведения и редактура текста не всегда должны идти в одном commit.

Исправление без потерь

Если notes.txt случайно изменился и это больше не нужно:

git restore notes.txt

Если файл уже в staged, но коммитить его рано, используйте:

git restore --staged task-service.js

Изменения не удаляются с диска, они просто возвращаются в статус «изменённый».

Удаление и перемещение файлов

Если файл устарел:

git rm notes.txt
git commit -m "docs: remove obsolete scratch note"

Если нужно переместить файл, сначала создайте папку docs через Finder, Проводник Windows или IDE. Затем выполните:

git mv README.md docs/README.md
git add docs/README.md
git commit -m "docs: move main README to docs"

git mv явно показывает намерение и упрощает ревью.

Практика для task-service

1. Добавьте в task-service.js защиту от дублирующихся задач.
2. Расширьте docs/README.md и создайте notes.txt как временный черновик.
3. Подготовьте к коммиту только task-service.js и docs/README.md.
4. Проверьте, что notes.txt не попал в commit, и закройте лишнее через restore.

После этого этапа вы можете проверять изменения до коммита и осмысленно разделять работу по intent.

Практический рычаг качества коммитов

Если в вашем change-set появляются две разные идеи, лучше сделать два commit-а. Да, это занимает больше времени в моменте, но экономит время при ревью и истории. В больших задачах task-service такая дисциплина особенно заметна: проще объяснить и проще откатывать.

Еще один полезный паттерн: для больших правок сначала делайте diff по смысловым блокам (логика → документация → конфигурация), потом stage и commit по этому порядку. Это делает логику изменений прозрачной как для вас, так и для будущих коллег.