↓Перейти к содержанию
  1. Git: руководства и команды/

git push --force и --force-with-lease: когда и как использовать

·9 минут·

Когда вы работаете над веткой и совершаете новые коммиты, обычная команда git push отправляет ваши изменения на удалённый сервер без проблем. Но что происходит, если вы переписали историю вашей ветки? Например, выполнили git commit --amend для редактирования последнего коммита, git rebase для переупорядочивания коммитов или git reset для отката на несколько коммитов назад?

В этих случаях обычный git push будет отклонен. Git защищает вас от случайного стирания коммитов на удалённом сервере. Однако, когда вы уверены в своих действиях и работаете на личной ветке, вам нужен способ перезаписать удалённую историю. Здесь на помощь приходят git push --force и его более безопасная версия git push --force-with-lease.

В этой статье мы разберём:

  • Почему обычный push отказывается работать после редактирования истории
  • Опасность --force и почему её следует избегать
  • Почему --force-with-lease — это правильный выбор
  • Когда force push уместен, а когда это категорический запрет
  • Как настроить безопасное поведение по умолчанию

Почему обычный push не работает после amend/rebase #

Давайте рассмотрим конкретный сценарий. Вы создали ветку и совершили три коммита:

$ git log --oneline
abc1234 Третий коммит
def5678 Второй коммит
ghi9012 Первый коммит

Вы отправили эту ветку на сервер:

$ git push origin feature-branch

Но потом вы понимаете, что в последнем коммите содержится ошибка. Вы решаете исправить её с помощью git commit --amend:

$ git commit --amend -m "Третий коммит (исправленный)"

Локально ваша ветка теперь выглядит так:

$ git log --oneline
abc5555 Третий коммит (исправленный)  # новый хеш!
def5678 Второй коммит
ghi9012 Первый коммит

Обратите внимание: хеш последнего коммита изменился с abc1234 на abc5555. Это потому что amend создаёт новый коммит вместо изменения старого.

Теперь вы пытаетесь отправить эту ветку:

$ git push origin feature-branch
To github.com:user/repo.git
 ! [rejected]        feature-branch -> feature-branch (non-fast-forward)
error: failed to push some refs to 'github.com:user/repo.git'
hint: Updates were rejected because the tip of your branch is behind its remote counterpart.

Что произошло? На удалённом сервере последний коммит всё ещё имеет хеш abc1234, а вы пытаетесь отправить abc5555. Git видит это как конфликт и защищает удалённую ветку от стирания. Это разумная защита, потому что если бы кто-то другой работал на этой ветке и уже отправил свои коммиты, переписание истории привело бы к потере их работы.

git push –force: опасный вариант #

Самый прямолинейный способ решить проблему — использовать флаг --force (или -f):

$ git push origin feature-branch --force
# или короче:
$ git push -f origin feature-branch

Эта команда говорит Git: «Я знаю, что делаю. Перепишите удалённую ветку нашей локальной версией. Полностью и без вопросов».

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

Почему это опасно?

Представьте, что вы работаете в команде. На ветке feature работают два человека: вы и ваш коллега Иван. Вот что происходит:

  1. 09:00 — Вы оба начинаете с одного коммита A
  2. 09:15 — Вы добавляете коммит B, Иван добавляет коммит C
  3. 09:30 — Вы выполняете git rebase main и получаете новый коммит B' с другим хешем
  4. 09:31 — Вы выполняете git push -f origin feature
  5. 09:32 — Иван пытается выполнить git push origin feature

Что произойдёт? Его push будет отклонен, потому что он отстал от B'. Но когда Иван выполнит git pull origin feature, его локальная ветка изменится, и его коммит C будет потерян (или по крайней мере сложнее его найти в истории). Это произойдёт без каких-либо явных предупреждений.

Главная опасность: --force не проверяет, изменилась ли удалённая ветка с момента вашего последнего git fetch. Если кто-то другой отправил коммиты, которые вы не знаете, --force просто сотрёт их.

git push –force-with-lease: безопасный вариант #

Вот здесь на помощь приходит --force-with-lease:

$ git push origin feature-branch --force-with-lease

Эта команда работает так:

  1. Git проверяет, какой хеш находится на удалённой ветке в данный момент
  2. Если этот хеш совпадает с тем, что вы помните с момента последнего git fetch, push выполняется
  3. Если удалённая ветка изменилась (кто-то отправил новые коммиты), push отклоняется
$ git push origin feature-branch --force-with-lease
! [rejected]        feature-branch -> feature-branch (fetch first)
error: failed to push some refs to 'github.com:user/repo.git'
hint: Updates were rejected because the remote ref is ahead of the local ref.
hint: You updated the local ref, and then someone else must have updated
hint: the remote ref to be at a different commit. (forced update)

Это сообщение об ошибке говорит вам: «Подожди, удалённая ветка изменилась. Сначала выполни git fetch, чтобы синхронизировать локальную информацию о удалённой ветке, а потом попробуй ещё раз».

Более строгий вариант с явным хешем #

Если вы хотите быть ещё более осторожны, можете указать конкретный хеш, который вы ожидаете на удалённом сервере:

$ git push origin feature-branch --force-with-lease=feature-branch:abc1234

Это говорит: «Отправь мою ветку, но только если на сервере находится коммит abc1234. Если там что-то другое, откажи».

Это наиболее безопасный вариант, потому что вы явно указываете ровно то состояние, которое ожидаете найти на сервере.

Когда force push нужен и безопасен #

Force push допустим в следующих ситуациях:

1. Личная ветка, на которой работаете только вы #

Если ветка действительно только ваша и никто другой не отправляет коммиты, вы можете безопасно использовать --force-with-lease:

$ git commit --amend -m "Исправленное сообщение"
$ git push origin my-feature --force-with-lease

2. Исправление коммита перед review pull request’а #

Часто вы отправляете pull request, а затем замечаете опечатку или ошибку в одном из коммитов. Вместо создания нового коммита с исправлением, вы можете использовать amend и --force-with-lease:

# Исправьте файлы
$ git add .
$ git commit --amend --no-edit
$ git push origin feature-branch --force-with-lease

Рецензент увидит обновленный коммит вместо двух отдельных коммитов. Это делает историю чище.

3. Переупорядочивание коммитов после rebase #

$ git rebase main
$ git push origin feature-branch --force-with-lease

В этом случае вы переупорядочили свои коммиты, чтобы они были на основе последней версии main. Это нормально, если ветка — только ваша.

Пример полного сценария #

# Вы работаете на ветке feature
$ git log --oneline
abc1234 Исправление ошибки в парсере
def5678 Добавление функции парсинга

# Вы замечаете синтаксическую ошибку в последнем коммите
$ vim parser.py  # исправляете ошибку
$ git add parser.py
$ git commit --amend --no-edit

# Теперь локально
$ git log --oneline
abc5555 Исправление ошибки в парсере  # новый хеш
def5678 Добавление функции парсинга

# Отправляете с force-with-lease (более безопасно, чем просто --force)
$ git push origin feature --force-with-lease

Когда force push категорически запрещён #

Есть критические ветки, где force push должен быть полностью запрещён:

1. Ветка main (или master) #

Это главная ветка проекта. Если вы перепишете её историю, весь проект может сломаться:

# НИКОГДА не делайте этого!
$ git push origin main --force  # ❌ ОПАСНО!

2. Ветка develop (или любая общая ветка) #

Если на этой ветке работают несколько разработчиков, force push повредит их работу:

# НИКОГДА не делайте этого!
$ git push origin develop --force  # ❌ ОПАСНО!

3. Ветка production #

Если эта ветка используется для развёртывания на production сервере, force push может привести к отключению сервиса:

# НИКОГДА не делайте этого!
$ git push origin production --force  # ❌ СМЕРТЕЛЬНО ОПАСНО!

Защита ветвей с GitHub/GitLab #

Большинство хостингов репозиториев позволяют защитить критические ветки от force push:

GitHub:

  1. Перейдите в Settings → Branches
  2. Нажмите “Add rule”
  3. В “Branch name pattern” введите main или develop
  4. Включите опцию “Require a pull request before merging”
  5. Включите опцию “Dismiss stale pull request approvals when new commits are pushed”
  6. Включите опцию “Restrict who can push to matching branches” и выберите нужные роли

GitLab:

  1. Перейдите в Settings → Repository
  2. Раскройте “Protected branches”
  3. Выберите ветку
  4. В “Allowed to push” выберите “Maintainers”
  5. В “Allowed to force push” выберите “No one”

Настройка безопасного поведения #

Создание алиаса для –force-with-lease #

Вместо того чтобы каждый раз набирать длинную команду, создайте алиас в .gitconfig:

$ git config --global alias.pushf 'push --force-with-lease'

Теперь вы можете просто написать:

$ git pushf origin feature

Добавьте флаг в ~/.gitconfig вручную:

[alias]
    pushf = push --force-with-lease
    pushfv = push --force-with-lease --verbose

Изменение push.default для большей безопасности #

По умолчанию git push отправляет ветку с тем же именем на удалённый сервер. Но вы можете настроить более безопасное поведение:

$ git config --global push.default upstream

Это значит, что git push будет отправлять только текущую ветку на её upstream ветку (ту, на которую она настроена для отслеживания). Это предотвращает случайную отправку в неправильную ветку.

Запрет –force для определённых ветвей на клиенте #

Вы можете добавить pre-push hook, который будет предотвращать --force для определённых ветвей:

#!/bin/bash
# .git/hooks/pre-push

protected_branches="^(main|develop|production)$"
current_branch=$(git rev-parse --abbrev-ref HEAD)

if [[ $current_branch =~ $protected_branches ]]; then
    echo "❌ Ошибка: push в $current_branch с флагом --force запрещён!"
    exit 1
fi

Сделайте файл исполняемым:

$ chmod +x .git/hooks/pre-push

FAQ #

Вопрос 1: Почему –force-with-lease не защищает меня, если я выполнил git fetch?

Хороший вопрос. --force-with-lease проверяет состояние на момент вашего последнего git fetch. Если прошло время между fetch и push, и в этот период кто-то другой отправил коммиты, --force-with-lease всё равно выполнится (потому что вы знаете о последнем состоянии). Это нормальное поведение — предполагается, что вы видели эти коммиты и сознательно их перезаписываете. Если вы хотите максимальную защиту, используйте явный хеш: git push --force-with-lease=branch:HASH.

Вопрос 2: Можно ли восстановить коммиты, которые были потеряны из-за force push?

Да! Если force push произошёл на удалённом сервере, вы можете использовать git reflog локально, чтобы найти потерянные коммиты. На сервере GitHub/GitLab обычно ведёт логи всех изменений, и вы можете обратиться в техническую поддержку. Но самый надёжный способ — никогда не использовать --force на общих ветках.

Вопрос 3: Как запретить force push для всей команды?

Используйте защиту ветвей на хостинге репозитория (GitHub, GitLab, Bitbucket). Настройте branch protection rules так, чтобы только определённые роли (например, администраторы) могли использовать force push. Это работает эффективнее, чем локальные hooks.

Вопрос 4: Что произойдёт, если я выполню force push на ветку с открытым pull request’ом?

На GitHub и GitLab pull request останется открытым, но будет отмечено, что ветка изменилась. Рецензент увидит, что коммиты обновились. Если pull request требует утверждения перед merge, потребуется новое утверждение.

Вопрос 5: В чём разница между git pull –force и git push –force?

git pull --force — редкая команда, которая не рекомендуется. Она может привести к потере локальных изменений. Используйте вместо этого git fetch и git rebase, или git reset --hard origin/branch, если хотите полностью синхронизироваться с сервером.

Заключение #

  • Никогда не используйте git push --force без глубокого понимания того, что вы делаете
  • Всегда используйте git push --force-with-lease вместо --force
  • Force push допустим только на личных ветках, где работаете только вы
  • Запретите force push на main, develop, production и другие общие ветки с помощью branch protection
  • Создайте алиас git pushf для git push --force-with-lease, чтобы сделать это стандартной практикой
  • Если сомневаетесь, используйте обычный git push — это никогда не причинит вреда

Force push — это мощный инструмент, но с большой мощностью приходит большая ответственность. Используйте --force-with-lease, понимайте, когда это необходимо, и всегда защищайте критические ветки.

Дополнительная информация доступна в статьях /ru/git/git-push/, /ru/git/git-rebase/ и /ru/git/git-commit-amend/.