Git - отменить git pull, как вернуть репозитории в старое состояние

Общее

Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит)

Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс (), потом «сохраняем» ()

Любой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Ключ к пониманию

Ключ к пониманию концепции git — знание о «трех деревьях»:

Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
Директория — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.

У всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.

Простейший цикл работ

Редактирование, добавление, удаление файлов (собственно, работа).
Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
Коммит (фиксация изменений).
Возврат к шагу 1 или отход ко сну.

Указатели

— указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
— указатель на коммит, с которого вы только что переместили (командой , например).
Ветка (, etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
Теги — простые указатели на коммиты. Не перемещаются.

Перед началом работы нужно выполнить некоторые настройки:

Если вы в Windows:

Длинный вывод в консоли: Vim

Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w.

# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти
```bash
# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти

# Ввод в командном режиме
:q!             — выйти без сохранения
:wq             — сохранить файл и выйти
:w filename.txt — сохранить файл как filename.txt

Отмена изменений

Отменить последний коммит:: Внесенные изменения будут сохранены. Это сработает только в том случае, если вы еще не опубликовали свои изменения!

Отменить все изменения в файле до последнего коммита:

Внимание!Вы НЕ сможете восстановить изменения после этой команды! Убедитесь, что вы отменяете изменения в нужном файле.

Отменить конфликтный merge:

Получить версию файла из определенной ветки:

Восстановить файл из указанного коммита:

Извлечь определенную версию файла из истории GIT в указанный путь

Отменить последний коммит, который ушел на сервер:

* Команда revert собирает patch отражающий нужный коммит, разворачивает его и добавляет новый коммит для отката (коммит, конечно же, будет видет виден в истории). Таким образом, при merge и push нет необходимости использовать —force.

Отменить 3 последних коммита, которые уже ушли на сервер:

Внимание!

Не используйте без критической на то необходимости --force:

Это единственная команда Git, которая делает необратимые изменения!

Вообще, делать reset —hard или rebase в опубликованной истории крайне не желательно. Лучше создать новую ветку, собрать в ней нужное состояние и слить ее с вашей веткой.

Откатить коммиты и оставить изменения в виде не проиндексированных:

Как перенести изменения из локального репозитория в удаленный репозиторий в Git

Чтобы протолкнуть некоторые изменения в удаленный репозиторий, этот репозиторий должен, прежде всего, содержать некоторые коммиты в локальной системе. Поэтому в этом разделе мы сначала создадим некоторые изменения в репозитории. Во-вторых, мы зафиксируем эти изменения и, наконец, отразим их в удаленном репозитории.

Перед созданием изменений в репозитории убедитесь, что вы выполнили следующие операции:

У вас раздвоенный репозитория на GitHub.
Вы клонировали один и тот же репозиторий на локальную машину.

В качестве хорошей практики сначала проверьте, что у вас есть чистый репозиторий с помощью команды git status (никаких ожидающих изменений для фиксации).

После выполнения команды git status появятся следующие строки:

On branch master: означает, что в данный момент мы находимся в главной ветви. Поскольку других ветвей пока нет, мы по умолчанию находимся в главной ветви.

Your branch is up to date with origin/master: Origin — это имя удаленного репозитория, которое мы дали при подключении локального репозитория к удаленному репозиторию.

Последовательность действий

Перечислите все файлы с командой ls в репозитории.

Так как существует только один файл (README.md это всего лишь инструкция), давайте внесем некоторые изменения в его содержание.

Откройте файл с помощью вашего любимого редактора и внесите в него любые изменения.
Мы изменили файл на следующий код.

Добавьте внесенные изменения в промежуточную область и зафиксируйте их.

Примечание: GitHub и Git распознают любые изменения только через коммиты (commits). Если пользователь не зафиксировал изменения и пытается протолкнуть их на GitHub, он отобразит сообщение “Everything is up-to-date”

Введите следующую команду, чтобы перенести эти изменения в репозиторий GitHub, и нажмите клавишу enter.

git push origin master

Пользователь получает приглашение предоставить учетные данные с помощью GitHub в качестве части безопасности. Введите свои учетные данные и нажмите на кнопку входа в систему.

Как только пользователь получит одобрение и изменения объединятся, он получит следующее сообщение в Git Bash.

Примечание: последние две строки выглядят следующим образом:

https://github.com/harishrajora805/ToolsQA.git: URL-адрес репозитория, который отражает изменения.

1в4522а..285f559: показывает хэш-значение обеих ветвей. Таким образом, хэш-значение конечного коммита, отраженного на GitHub, равно 285f559.

master -> master: строка master — > master показывает исходную ветвь, из которой происходит слияние с целевой ветвью. В приведенном выше сценарии обе ветви являются главными.

Строка Writing Objects: 100% имеет важное значение. В Git можно сказать, была ли команда push выполнена успешно или нет, только взглянув на эту строку

Если она показывает 100%, то все изменения успешно перенесены в облако.

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

7 ответов

Лучший ответ

GitHub теперь поддерживает закрытие запроса на перенос

В основном вам нужно проделать следующие шаги:

Посетите страницу запроса на вытягивание
Нажмите на запрос на вытягивание
Нажмите кнопку «закрыть запрос на перенос»

Пример (кнопка в самом низу):

Таким образом, запрос на перенос закрывается (и игнорируется) без его объединения.

166

Avatar
31 Авг 2020 в 07:00

В духе DVCS (например, «Распределенный») вы не отменяете то, что опубликовали: Запросы на вытягивание — это, по сути, патчи, которые вы отправили (обычно по электронной почте, здесь через веб-приложение GitHub), и вы также не отмените электронное письмо;)

Но поскольку система запросов на вытягивание GitHub также включает раздел обсуждения, в котором вы могли бы высказать свое беспокойство получателю этих изменений, попросив его / ее игнорировать 29 из 30 ваших коммитов.

Наконец, помните:

a / у вас есть раздел предварительного просмотра при выполнении запроса на перенос, позволяющий увидеть количество коммитов, которые будут включены в него, и просмотреть их разницу.
б / желательно перебазировать работу, которую вы хотите опубликовать, как запрос на вытягивание поверх удаленной ветки, которая получит указанную работу. Затем вы можете сделать запрос на перенос, который получатель может безопасно применить в ускоренном режиме.

Community
23 Май 2017 в 12:02

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

Roch
27 Сен 2013 в 10:15

Перейдите на вкладку разговора, затем спуститесь, там есть одна кнопка » закрыть запрос на перенос «, используйте эту кнопку, чтобы закрыть запрос на перенос, взять ссылку на прикрепленное изображение

Mohit
29 Авг 2016 в 17:01

Если вы открыли PR на gitHub, но он еще не объединен и вы хотите избавиться от него, а не просто закрыть, выполните эту простую команду:

Ivan S.
1 Апр 2021 в 18:24

Супер ЛЕГКИЙ способ закрыть Pull Request — ПОСЛЕДНИЙ!

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

RICHARD ABRAHAM
20 Авг 2020 в 20:19

У меня такая же проблема. Что я сделал

Перейдите на страницу запроса на слияние.
Отметьте фиксацию с помощью галочки слева от фиксации.
В раскрывающемся списке «Отметить как» нажмите «Закрыть».

Вот и все.

Faysal Ahmed
2 Мар 2021 в 11:43

Общие вопросы по Git Pull

Почему мы обычно пишем команду git pull как git pull origin master?

‘git pull origin master’ будет извлекать и обновлять только определенную ветвь под названием master и origin в удаленном репозитории. Часто ветвь по умолчанию в Git является главной ветвью, и она постоянно обновляется. Пользователь может использовать любое имя ветви для извлечения этой ветви с пульта дистанционного управления.

Неужели git тянет за собой все ветки?

Да, если используется только команда «git pull», то Git будет извлекать все обновленные ссылки на локальные ветви, которые отслеживают удаленные ветви.

Могу ли я отменить git pull?

Да, мы можем отменить изменения, сделанные Git Pull командой » git reset –hard’. Git reset hard сбрасывает ветвь только что извлеченным пользователем данные, в то время как опция hard изменяет файл в рабочем дереве в соответствии с файлами в ветви.

Опции в Git Pull

Как и любая другая команда в Git, команда pull также может похвастаться некоторыми быстрыми опциями, которые помогают в естественном и эффективном использовании команды.

No-Commit

Опция no-commit будет извлекать изменения, но слияние не будет явной фиксацией, то есть фиксация слияния не будет указана в списке.

git pull –no-commit

Rebase

Опция rebase создает линейную историю коммитов после слияния одной ветви в другую. В дополнение к этому, опция Git rebase помогает в прозрачном рабочем процессе. Более того, несмотря на то, что она включает в себя несколько ветвей, она выглядит как одна ветвь с линейным рабочим процессом.

Git Branches перед Rebase

Git Branches после Rebase

Команда может выполняться следующим образом:

git pull –rebase

Недостатком использования команды Git rebase является то, что она затрудняет разработчикам и тестировщикам распознавание небольших коммитов и изменений, сделанных в репозитории, поскольку история коммитов становится линейной. Проекты с открытым исходным кодом часто не используют команду «rebase» по этой причине, но, как всегда, дело зависит от личного выбора.

Что такое Git Pull?

Git pull — это волшебный способ выполнить комбинированную операцию git-fetch и git-merge с помощью одной команды. «Pull” означает, что пользователь пытается извлечь что-то из хранилища.

Git Pull выполнит Git Fetch, не сообщая пользователю, и объединит изменения автоматически, не спрашивая у пользователя.

Выполнение команды git pull приведет к слиянию изменений без уведомления пользователя или отображения того, какие изменения объединяются.

Пользователь просто уведомляется о результате выполнения команды, была ли операция успешной или неудачной, включая любые предупреждения и т. д. Это может показаться рискованным, но git pull используется очень часто. “Рискованно” в том смысле, что git pull объединит даже те изменения, которые не требуются, или те, которые вы не хотите объединять. Git Pull предполагает, что любое изменение, произошедшее в репозитории, требует слияния.

Побочным эффектом или предупредительным механизмом, который эта команда приносит с собой, является “слияние-конфликт.” Git pull иногда вызывает предупреждение о “слиянии-конфликте” в Git.

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

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

Тяжесть ситуации в том, что вы не можете просто сделать , поскольку у вас локально нет коммитов, которые нужно восстановить (и у вас не получиться скачать их с помощью ).

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

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

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

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

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

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

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

git pull —rebase

Рассмотрим команду pull с параметром rebase:

git pull --rebase

На результат слияния параметр —rebase не влияет, единственное, что он делает — меняет вид истории коммитов.

До команды pull

Допустим, мы разветвились с удаленным репозиторием на коммите D:

До pull

Наши локальные коммиты с момента разветвления — это нижние E, F, G, а в удаленном репозитории с тех пор появились коммиты A, B, C. Нам надо их накатить сверху на наши коммиты E, F, G, что собственно и делает команда pull.

Обычный pull

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

git pull

pull —rebase

Если же мы выполним:

git pull --rebase

то история локальных коммитов будет выглядеть по другому (при том же результате слияния файлов):

git pull —rebase

При просмотре истории коммитов мы просто увидим ряд коммитов из основной ветки A, B, C, идущих за нашими локальными E, F, G. Кому-то такой вид выглядит чище, хотя разницы в итоговом содержимом файлов нет.

Инструмент 2: Pull Requests

Pull Requests — отличный способ внести свой вклад в репозиторий, сделав его форк. В конце дня, если мы хотим, мы можем отправить pull request владельцу репозитория, чтобы объединить наши изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии.

Давайте теперь рассмотрим основные шаги для pull request.

Инициирование pull request

В Github есть две модели для pull request:

Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.

Здесь мы видим рабочий процесс между двумя пользователями ( и ) для модели Fork and Pull:

Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:
Это создаст точную копию репозитория в вашем собственном аккаунте
Выберите URL-адрес SSH, чтобы он запрашивал вашу парольную кодовую фразу SSH вместо имени пользователя и пароля каждый раз, когда вы делаете или . Затем мы будем клонировать этот репозиторий на наш локальный компьютер:
Как правило, мы создадим новую ветку git для каждой новой задачи. Это хорошая практика, потому что в будущем, если мы продолжим обновление ветки после некоторых обсуждений, запрос на перенос будет автоматически обновляться. Давайте создадим новую ветку, чтобы внести очень простое изменение в файл :
После внесения соответствующих дополнений для создания новых функций мы просто передадим новые изменения и проверку в ветку git master:
На этом этапе мы запушим ветку в удаленный репозиторий. Для этого мы сначала перейдем на ветку с новой задачей, а так же на псевдоним для удаленного репозитория. Затем мы будем пушить изменения с помощью :
На нашей развязанной странице Github репозитория мы перейдем к ветке с новой функцией, а затем нажмите кнопку «Pull Request».
После отправки пул реквеста он напрямую приведет нас к странице запроса в исходном репозитории. Мы увидим наш запрос на pull.
После обсуждения возможно, что владелец форкнутого репозитория может захотеть добавить изменения в новую функцию. В этом случае мы выберем одну и ту же ветку на нашей локальной машине, зафиксируем ее и запушим ее обратно на Github. Когда мы заходим на страницу запроса в оригинальном репозитории, он будет автоматически обновляться!

Слияние пул реквеста

Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:

Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:
Слияние на наших локальных машинах: в других случаях могут возникнуть конфликты слияния, и после нажатия кнопки «Информация» у Github будут четкие инструкции о том, как мы можем объединить ветвь на нашей локальной машине, потянув за изменения из ветви контрибьютера:

Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.

Когда использовать Git Pull?

Пользователь может задаться вопросом, когда он должен использовать Git fetch и когда он должен перейти к команде Git pull. Git fetch часто считается более безопасной версией Git Pull, и ее следует использовать, если пользователь новичок в Git. Если пользователь достаточно уверен в себе, он может использовать команду git pull только в чистом рабочем каталоге (без зафиксированных изменений).

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

Использование команды Git pull ничем не отличается от использования команды Git merge. Просто имейте в виду, что git pull-это короткий путь к git fetch и git merge. Это означает, что нам не нужно выполнять git fetch и git merge, и изменения будут включены непосредственно.

Изменение истории коммитов

rebase

Источник (спасибо автору за разъяснение): http://tonyganch.com/git/rebase/

Внимание!

git rebase меняет hash коммитов! Поэтому, git rebase можно делать только в локальном репозитории, и только до публикации коммитов (push)!

Слияние коммитов

Начать процесс интерактивного слияния 2-х последних коммитов:

Примечание

После запуска rebase — откроется текстовый редактор. Сверху идут старые коммиты, внизу более свежие.

Доступные действия с коммитами в текстовом редакторе:

Указать как основной коммит-приемник при слиянии.

Слить коммиты, используя комментарий основного pick-коммита.

Слить коммиты вместе с их комментариями.

Изменить комментарий коммита. Укажите только опцию , а имя коммита вы укажете при выходе из интерактивного режима.

Для удаления коммита — просто удалите строку в интерактивном редакторе коммитов.

Управление процессом rebase

Отменить незавершенный rebase:

Откатить успешный rebase можно только с помощью reset —hard:

Продолжить выполнение команды rebase:

Пропустить наложение коммита и перейти к следующему:

Пример слияния коммитов

Начать процесс интерактивного слияния коммитов в пределах 6-ти последних:

Примечание

При слиянии коммита, Git вливает его в предыдущий в списке. Вы можете изменить порядок коммитов перед слиянием. Например:

Подготовить коммиты к слиянию:

Состояние коммитов:

Выполнить сливание в автоматическом режиме:

Изменить комментарий к последнему коммиту:

Изменить комментарии в диапазоне последних 3-х коммитов:

Сдвинуть коммиты

Принять изменения и сдвинуть свои незапушенные коммиты вверх (как будто вы сделали pull, до того как закоммитили изменения):

Наложить коммиты из ветки my-fix на последний коммит ветки stage:

Внимание!

Обратите внимание, что при разрешении конфликтов, theirs — это изменения из ветки, в которую мы влили коммиты и сдвинули наш коммит на верх, а ours — это изменения, которые мы получили из чужих новых коммитов. После разрешения конфликтов — вызовите:. #cvs, #git

#cvs, #git

Git push

Команда в ходе выполнения переносит все изменения, внесенные юзером, в удаленный репозиторий (например, такой как GitHub):

Git push 'remote_name' 'branch_name'

Чтобы отправить данные в удаленный репозиторий, нужно удостовериться, что все перемены зафиксированы в локальном репозитории. После того, как вы внесете изменения локально, вы сможете поделиться ими с помощью . Но прежде чем отправлять какие-либо перемены в удаленную ветку, рекомендуется запустить команду . Это обновит локальную ветвь.

Вынужденная команда push при корректировке коммитов:

# make changes to a repo and git add

              git commit --amend

# update the existing commit message

       git push --force origin main

Команда применяется для обновления прошлого коммита. Только после этого измененный коммит вынужденно выпускается с помощью команды .

Git merge

Команда связывает ряд коммитов в одно целое. В свою очередь создает коммит слияния, где и объединяются изменения обеих последовательностей.

Конфликт в слиянии

Бывают случаи, когда находит конфликт в слиянии и к файлам присоединяются индикаторы: , и :

<here is some content not affected by the conflict

<<<<<<< main

this is conflicted text from main

=======

this is conflicted text from feature branch

>>>>>>> feature branch;

По завершению слияния, выполните команду : таким образом вы проинформируете, что причина конфликта разрешена

Важно запомнить, что конфликты допустимы только в трехслойном слиянии и никогда не возникают при ускоренном.

Подмодули

Клонирование репозитория с подмодулями

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

Запуск данной команды эквивалентен запуску команды:

после обычного клонирования репозитория

Обновление подмодулей

Подмодуль ссылается на конкретную коммит в другом репозитории. Чтобы получить
точное состояние всех подмодулей необходимо запустить:

Для получения состояния последнего коммита всех подмодулей необходимо выполнить
следующую команду:

или использовать аргументы по умолчанию команды git pull:

Эта команда просто обновляет локальную рабочую копию. При запуске команды git status
каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо
зафиксировать изменения:

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

Добавление подмодулей

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

После этого необходимо добавить и зафиксировать новый файл .gitmodules. В нём описано
какие подмодули следует клонировать при запуске команды git submodule update

6 ответов

Лучший ответ

Прежде чем ответить, давайте добавим некоторую предысторию, объясняющую, что это за .

First of all what is HEAD?

— это просто ссылка на текущий коммит (последний) в текущей ветке. В любой момент времени может быть только один (исключая ).

Содержимое хранится внутри и содержит 40 байтов SHA-1 текущего коммита.

detached HEAD

Если вы не используете последнюю фиксацию — это означает, что указывает на предыдущую фиксацию в истории, она называется detached HEAD.

В командной строке это будет выглядеть так — SHA-1 вместо имени ветви, поскольку не указывает на кончик текущей ветви:

Несколько вариантов того, как восстановить систему с отключенной HEAD:

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

Вы всегда можете использовать . отобразит любое изменение, которое обновило , и проверка нужной записи рефлога вернет к этой фиксации.

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

Это вернет вас к желаемой фиксации

«Переместите» ГОЛОВУ назад к желаемому коммиту.

Примечание. (Начиная с Git 2.7) вы можете также используйте git rebase —no-autostash.

«Отменить» данный диапазон фиксации или фиксации. Команда сброса «отменит» любые изменения, сделанные в данном коммите. Новый коммит с патчем отмены будет зафиксирован, в то время как оригинальный коммит останется в истории.

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

439

Community
20 Июн 2020 в 09:12

Сначала локально:

Чтобы убедиться, что вы на правильной позиции, проверьте:

Вы увидите что-то вроде:

Затем перепишите историю в ветке удаленного отслеживания , чтобы отразить изменение:

Abel
25 Июл 2020 в 20:57

Сегодня я по ошибке проверил фиксацию и начал работать над ней, сделав несколько коммитов в состоянии отсоединения HEAD. Затем я перешел в удаленную ветку с помощью следующей команды:

Затем

Наконец-то я получил все изменения в своей ветке, которые я сделал при отсоединении HEAD.

Peter Mortensen
27 Янв 2020 в 02:18

Когда вы запускаете команду , тогда HEAD отсоединяется от , и ветвь становится доступной дольше.

Вернитесь в предыдущее место, выполните пошаговую команду —

(скажите хозяин)

Вы вернетесь в предыдущее место с обновленным коммитом из удаленного репозитория.

Peter Mortensen
27 Янв 2020 в 02:16

Вопрос можно прочитать так:

Я был в отключенном состоянии с в и набрал (потому что я хотел раздавить). Теперь я передумал, как мне вернуться к в ?

Прямой ответ:

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

Оказывается, есть!

(или в моем случае )

Кстати, это было то же самое, что вернуться в предыдущий текущий каталог в * nix! Итак, ура, я выучил две вещи одним выстрелом.

Peter Mortensen
27 Янв 2020 в 02:14

Самое быстрое решение (всего 1 шаг)

Используйте

Вы увидите . Подтвердите, что это нужная ветка.

Краткое объяснение: эта команда вернет HEAD в последнее положение. См. Примечание о результатах в конце этого ответа.

Мнемоника: этот подход очень похож на использование для возврата в ранее посещенный каталог. Синтаксис и применимые случаи довольно хорошо совпадают (например, это полезно, когда вы действительно хотите, чтобы HEAD вернулся туда, где он был).

Более методичное решение (2 шага, но запоминающееся)

Быстрый подход решает вопрос ОП. Но что, если ваша ситуация немного отличается: скажем, вы перезапустили Bash, а затем обнаружили, что HEAD отключен. В таком случае, вот 2 простых, легко запоминающихся шага.

Используйте

Вы видите список существующих местных филиалов. Выберите название ветки, которое вам подходит.

Используйте

Вы увидите . Успех!