В чем разница git commit и git push

Что проверяют

Понимаете ли вы, что Git распределённый: у вас на машине полноценный репозиторий с историей, а удалённый это просто ещё одна копия. Следом обычно спрашивают про git pull и git fetch или про то, что делать, если push отклонили.

Как отвечать

Разведите команды по тому, где они меняют состояние:

• git commit: записывает снимок проиндексированных изменений в локальную историю текущей ветки. Сеть не нужна, коммит пока видите только вы. Файлы попадают в индекс через git add, сообщение задаётся флагом -m;
• git push: отправляет коммиты, которых нет на удалённом репозитории, и сдвигает там указатель ветки. Только после этого изменения видят коллеги, CI и превью-деплой;
• индекс (staging area): промежуточный слой между рабочей папкой и коммитом. Он позволяет собрать в коммит только часть правок, например через git add -p.

Полезно проговорить, что происходит при отказе. Если в удалённой ветке появились чужие коммиты, push по умолчанию отклоняется как non-fast-forward. Нужно забрать изменения (git pull --rebase или git fetch и затем git rebase), разрешить конфликты и отправить снова. Первый push новой ветки делают с -u, чтобы связать её с удалённой: git push -u origin feature/header.

Для фронтенда уместен практический штрих: хуки husky с lint-staged срабатывают на pre-commit, то есть локально и до push, а проверки в GitHub Actions или GitLab CI запускаются уже после отправки.

Где спотыкаются

Говорят, что commit «сохраняет на сервер». Это главная путаница: пока не было push, коммит живёт только на вашей машине и пропадёт вместе с ней.

Советуют при отказе push сразу делать git push --force. На общей ветке это стирает чужие коммиты. Если историю всё же нужно переписать, безопаснее --force-with-lease, и только в своей ветке.

Путают push и pull request. Push отправляет коммиты в ветку, а PR это функция GitHub или GitLab для ревью и слияния, к самому Git она отношения не имеет.