Почему git push отклоняется (rejected) — 3 причины и как починить

Пишешь git push, а в ответ — красное ! [rejected] main -> main (fetch first). Первая мысль: сломалось, всё пропало. Спокойно.

Смотри, rejected — это не поломка, а git тебя защищает. Он отказывается пушить, потому что боится затереть чужую работу или сделать что-то необратимое. Почти всегда причина — одна из трёх ниже. Разберём их по порядку, от самой частой.

Причина 1. За тобой ушёл сервер (самая частая)

Ты сделал коммит, но на сервере уже есть коммит, которого нет у тебя. Может, ты пушил с другого компьютера. Может, коллега успел раньше. Git видит, что ваши истории разошлись, и не хочет вслепую затирать то, что на сервере.

Сообщение выдаёт это словами fetch first или non-fast-forward.

Как проверить. Выполни git status — увидишь что-то вроде «your branch and 'origin/main' have diverged». Значит, дело именно в этом.

Как починить. Сначала забери с сервера чужие изменения и вплети свои поверх:

git pull --rebase
git push

--rebase аккуратно кладёт твои коммиты поверх серверных, без лишнего «мёржа». Если git сообщит о конфликте — два человека правили один и тот же кусок — он покажет, где именно, ты выбираешь верный вариант руками и продолжаешь. Это нормальная часть работы с git новичку, не ошибка.

Причина 2. Не та ветка или нет прав

Второй частый случай: ты пушишь не туда или тебе просто не разрешено.

• Защищённая ветка. У многих репозиториев main закрыт от прямого пуша — менять её можно только через pull request. Тогда push в main отобьётся, а push в свою ветку пройдёт.
• Чужой репозиторий. Ты клонировал чей-то проект, но прав на запись у тебя нет. Push вернёт ошибку доступа (403 / permission denied).

Как проверить. Глянь, куда целишься: git remote -v (тот ли репозиторий) и git branch (та ли ветка).

Как починить. Пушь в свою ветку и открывай pull request:

git switch -c моя-ветка
git push -u origin моя-ветка

Если это твой репозиторий, но доступа нет — почти всегда проблема в авторизации: протух токен или ключ. Тогда чинится обновлением доступа к GitHub, а не самим git.

Причина 3. Слишком большой файл

Реже, но бьёт больно. GitHub не принимает файлы больше 100 МБ — push с таким файлом отобьётся, даже если всё остальное идеально. Обычно это случайно закоммиченное видео, архив или папка сборки.

Как проверить. В тексте ошибки прямо назван файл и его размер («this exceeds GitHub's file size limit of 100 MB»).

Как починить. Убери тяжёлый файл из истории и добавь его в .gitignore, чтобы не вернулся:

git rm --cached огромный-файл.zip
echo "огромный-файл.zip" >> .gitignore
git commit -m "remove large file"
git push

Если большой файл нужен в репозитории (например, макет для дизайна) — для этого есть отдельный механизм, Git LFS. Но чаще всего такой файл просто попал случайно, и его надо убрать.

Почему нельзя просто продавить push силой?

Можно — git push --force затрёт серверную историю твоей. Но это опасно: ты сотрёшь чужие коммиты, которых у тебя не было, и вернуть их будет тяжело. Для новичка правило простое: сначала git pull, а --force — только когда точно понимаешь, что и зачем затираешь.

В чём разница между fetch, pull и push?

Коротко: push — отправить свои коммиты на сервер. fetch — скачать чужие, но пока не вплетать. pull — это fetch плюс сразу вплести к себе. Когда git просит fetch first, он имеет в виду: «забери чужое, разберись, потом отправляй своё». Больше команд — в шпаргалке по git.