Git push force что делает

Изучаем Git. Урок 19.
Зачем нужен git push —force
и что с ним может пойти не так

Полная стоимость курса — 2500 рублей. На текущий момент готовы не все уроки курса и Вы можете приобрести всего за 1000 рублей.

Чтобы оплатить курс, сначала нужно войти или зарегистрироваться

Регистрация

— Оплата через Яндекс Кассу
— При возникновении проблем с оплатой, входом или просмотром курса свяжитесь со мной любым способом:
ВК: Александр Шестаков, Email: webdevkin@gmail.com

План урока

• Работа в одиночку
• Как запушить ветку после перезаписи истории коммитов
• Что такое git push —force
• Работа в команде
• Какие могут быть проблемы при пуше с форсом
• Каким образом можно потерять коммиты
• Примеры из жизни
• Поиск решения проблем после неудачного git push —force
• 7 советов по работе с —force

Продолжительность видео — 35 минут

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
• 16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
• 24. Мердж-реквесты
• * 25. Форки

Git push — что это такое

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

Теперь раскроем тему более подробно.

Что есть Git

Git-репозиторий — это набор файлов, которые хранятся в папке .git. Просто набор файлов, и ничего более.

Git сохраняет в commit (коммит) содержимое всех файлов, сохраняя изменения в objects. Если файл не менялся, используется старый objects. Получается, что в коммит попадают только те файлы, в которые вносились исправления. Это экономит место в хранилище, ускоряет процесс обновления и позволяет в любой момент переключиться на нужный коммит, так как все коммиты видны в истории изменений.

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

Аренда облачного сервера для разработки, хостинга, обученияПодробнее

Git push и все-все-все

Итак, команда git push необходима для передачи содержимого локального репозитория в центральный, к которому имеют доступ другие разработчики из команды. С ней нужно быть осторожным, пушить в репозиторий стоит лишь в том случае, когда вы твёрдо уверены том, что готовы перезаписать основную ветку. В обратном порядке работает команда git fetch: она импортирует коммиты из основного репозитория в локальные.

Если упростить, то процесс отправки пушей выглядит так:

git push origin master

• Действие: push, отправить
• Адресат: origin, сервер
• Объект: master, имя ветки

Как ещё можно использовать команду git push?

git remote add link

Начать нужно с организации связей между репозиториями. Эта команда связывает локальную и центральную ветки. Вместо repository_name указываете имя репозитория (как правило, это origin), а вместо link — URL-адрес. Только после этой команды ваш пуш будет уходить в нужную ветку.

Команда отправки на публикацию выбранной ветки в удалённый репозитории (включая все коммиты и внутренние объекты). При этом создаётся локальная ветка в конечном репозитории. В целях защиты коммитов от перезаписи Git не позволяет публиковать данные, если в конечном репозитории невозможно выполнить быстрое слияние веток.

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

Отправка всех локальных веток на публикацию в удалённом репозитории.

git branch -D branch_name или git push origin :branch_name

Чтобы навести порядок, репозитории иногда нужно чистить. Вы можете полностью стереть ветку branch_name в локальном репозитории при помощи первой команды. Или стереть удалённую ветку — введя в консоли вторую команду.

Git умеет и показывать незапушенные коммиты. Чтобы их посмотреть, введите команду

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

On branch master

Your branch is ahead of ‘origin/master’ by 3 commits.

(use «git push» to publish your local commits)

Это значит, что три коммита ещё не запушены, а предлагаемые в них изменения не внесены в репозиторий.

А что ещё можно делать с Git?

Удалять локальные данные и ветки, которых нет в центральном репозитории, добавлять и удалять теги на сервере, просматривать все удалённые репозитории, и каждый из них в отдельности. В Git есть большое количество инструментов, которые упрощают разработку и позволяют быстрее выкатывать конечный продукт. Чтобы увидеть весь перечень команд, поддерживаемых Git, введите в консоли команду

Откат ошибочной команды git push —force

Иногда при работе с несколькими удалёнными репозиториями в git, может произойти страшное: git push —force в не тот remote и/или не в ту ветку.

Такое может случиться, например, если вы используете Deis, в котором деплой запускается при git push нужного коммита в сборщик, когда при отладке деплоя после очередного git commit —amend по запарке вместо git push deis master —force делается просто git push —force . Упс.

Как результат, последние коммиты коллег безвозвратно потеряны, и вы чувствуете неотвратимость их ярости…

Но это git, а значит всё можно починить!

Как чинить

Вариант самый простой и для ленивых

Немедленно врывайтесь в рабочий чат с воплем «кто последний пушил в branchname? форс-пушните вашу версию ветки!». С какой-то долей вероятности последним сделает git push —force именно тот коллега, у которого самая свежая версия кода.

Простой вариант: я последний пушил в ветку

Этот вариант прост тем, что у вас есть всё, что нужно для восстановления за 1 минуту, не выходя из консоли.

Перво-наперво: без паники. Не закрывайте терминал!

Сожалея о содеянном зайдите в чат и покайтесь, в том, что вы наделали.

В выводе команды git push —force найдите строчку, похожую на эту:

 + deadbeef. f00f00ba master -> master (forced update) 

Первая группа символов, подозрительно похожих на SHA коммита и есть наш ключ к спасению: deadbeef — это действительно коммит, который был в ветке master до того, как мы всё сломали. Теперь просто пушните этот коммит в ветку, которую вы поломали:

git push --force origin deadbeef:master 

Всё, вы всех спасли. Но больше так не делайте.

Сложный вариант: починить за кем-то

Иногда бывает, что git push —force сделали либо не вы, либо кто-то принял пачку Pull Request’ов в то время, пока вы веселились со своими экспериментами.

Тяжесть ситуации в том, что вы не можете просто сделать git push —force sha1:master , поскольку у вас локально нет коммитов, которые нужно восстановить (и у вас не получиться скачать их с помощью git fetch ).

Стоп! Без паники! Зайдите в чат, покайтесь, скажите, чтобы никто ничего не делал — вам понадобится время, чтобы всё вернуть.

Здесь нам поможет тот факт, что GitHub не удаляет коммиты, которые больше не принадлежат ни к какой ветке. Но, что усложняет задачу, не даёт их и стянуть с командной строки.

Если force-пуш сделали вы, то просто возьмите хэш коммита, который был в ветке до вас (как и в прошлом пункте). Если не вы, то можно зайти в ленту событий GitHub’а (на главной странице, в случае, если вы подписаны на репозиторий) и посмотреть, кто последний коммитил в эту ветку:

an hour ago Username pushed to master at org/repo - deadbeef Implement foo - deadf00d Fix bar 

Теперь перейдите по ссылке https://github.com/org/repo/tree/deadbeef (где deadbeef — хэш последнего коммита в ветке, которую вы перетёрли), откройте переключатель веток и тэгов, введите имя для новой ветки (например master-before-force-push ) и выберите пункт «Create branch».

Теперь через консоль можно получить недостающие коммиты:

$ git fetch From github.com:org/repo * [new branch] master-before-force-push -> origin/master-before-force-push

и теперь задача сводится к предыдущей:

git push --force origin origin/master-before-force-push:master 

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

git rebase origin/master 

Как избежать такого в дальнейшем?

1. В GitHub и GitLab есть функциональность под названием «защищённые ветки» (protected branches). Отметьте master , develop , stable или какие ещё ветки важны для вас как защищённые и система не даст вам выстрелить себе в ногу. Если force push всё же понадобится, то защиту всегда можно на время снять. См. документацию: https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
2. Используйте вместо ключа —force ключ —force-with-lease , который отменит push, если кто-то другой уже успел опубликовать новые коммиты. Подробнее здесь: https://developer.atlassian.com/blog/2015/04/force-with-lease/
3. Создайте алиасы для команд, которые должны делать git push —force , чтобы обезопасить себя от ошибок по неосторожности:

# ~/.gitconfig [alias] deploy = "!git push --force deis \"$(git rev-parse --abbrev-ref HEAD):master\"" 

Pro Tip: У команды git push также ещё очень хорошо сочетаются друг с другом ключи —force и —all , особенно, если вы отвлеклись от проекта на месяцок-другой. Попробуйте, если, конечно, вам всё ещё мало приключений…

Krystian Safjan’s Blog

working at Ernst & Young and writing about Data Science and Visualization, on Machine Learning, Deep Learning and NLP. There are also some howto posts on tools and workflows.

• PDF, ePUB, mobi format ebook, no DRM
• 50 questions and answers
• Stories from real projects
• 92 multiple choice quiz questions
• 80 pages

Understanding the Differences Between Git Push Force and Git Push Force-With-Lease

In the world of version control, Git is a powerful and widely-used tool for managing and tracking changes in your codebase. It allows multiple developers to work on the same project simultaneously, without conflicts. But when it comes to pushing changes to a remote repository, you might encounter some challenges. In this article, we will explore two Git commands that can help you overcome these challenges: git push —force and git push —force-with-lease . We will discuss their differences, common use cases, and lesser-known but super useful aspects of each.

• Git Push Force
  • Use Cases
    • Undoing a mistaken push
    • Cleaning up messy commit history
    • Updating a feature branch
    • Use Cases
      • Collaborative work
      • Rebasing or squashing commits
      • Updating a feature branch
      • Lease reference
      • Dry run

      Git Push Force

      git push —force is a command that allows you to overwrite the remote branch with your local branch, regardless of any conflicts or discrepancies between the two branches. This is a powerful command that should be used with caution, as it can result in lost commits and overwritten work.

      Use Cases

      Undoing a mistaken push

      If you accidentally pushed a commit with incorrect changes or to the wrong branch, you can use git push —force to overwrite the remote branch with the correct local branch.

      Cleaning up messy commit history

      If you want to clean up a cluttered commit history by squashing or rewriting commits, you can use git push —force to push the updated history to the remote branch.

      Updating a feature branch

      If you have a feature branch that has diverged significantly from the main branch, and you want to update it with the latest changes from the main branch, you can use git push —force to push the updated feature branch to the remote repository.

      Git Push Force-With-Lease

      git push —force-with-lease is a safer alternative to git push —force . It allows you to push changes to the remote branch only if the remote branch is at the same commit as the one you have locally. If the remote branch has been updated by someone else, the push will be rejected, preventing accidental overwrites.

      Use Cases

      Collaborative work

      When working with a team, using git push —force-with-lease helps ensure that you do not accidentally overwrite someone else’s work.

      Rebasing or squashing commits

      If you need to rebase or squash commits, using git push —force-with-lease is a safer option, as it ensures that you are not overwriting any new commits.

      Updating a feature branch

      Similar to git push —force , you can use git push —force-with-lease to update a feature branch with the latest changes from the main branch. However, it is a safer option, as it ensures that you are not overwriting any new commits on the remote branch.

      Lesser-Known Useful Features

      Lease reference

      git push —force-with-lease accepts an optional argument, the lease reference, which allows you to specify the expected commit of the remote branch. This adds an extra layer of safety by ensuring that the remote branch is at the exact commit you expect before pushing.

      git push --force-with-lease=origin/main:

      Dry run

      By adding the —dry-run option, you can check if the push would succeed without actually pushing the changes. This can help you avoid potential conflicts and overwrites.

      git push --force-with-lease --dry-run 

      Comparing Git Push Force and Git Push Force-With-Lease

      Command	Overwrites Remote Branch	Safety	Use Cases
      git push —force	Yes	Low	Undoing a mistaken push, cleaning up messy commit history, updating a feature branch
      git push —force-with-lease	No, only if the remote branch is at the same commit as the local branch	High	Collaborative work, rebasing or squashing commits, updating a feature branch with additional safety

      Похожие публикации:

      1. Как выучить матанализ
      2. Как поставить картинку поверх всех окон
      3. Как установить django
      4. Мкс на какой высоте летает от земли