git reset hard origin master что делает

Доходчивое объяснение Git Reset

Перевод статьи «Git Reset Explained – How to Save the Day with the Reset Command».

«Помогите! Я закоммитил не в ту ветку!» «Ну вот, опять… Где мой коммит?» Знакомые ситуации, правда?

Я такое слышал неоднократно. Кто-то окликает меня по имени и просит помочь, когда у него что-то пошло не так с git. И такое происходило не только когда я учил студентов, но также и в работе с опытными разработчиками.

Со временем я стал кем-то вроде «того парня, который разбирается в Git».

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

Бывает, мы отправляем коммит не в ту ветку. Бывает, теряем часть написанного кода. А можем и добавить в коммит что-то лишнее.

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

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

В прошлом посте я рассказывал о внутреннем устройстве Git. И хотя понимать его полезно, читая теория практически всегда недостаточна. Как применить свои знания внутреннего устройства git и использовать их для решения возникающих проблем?

Исходные условия — рабочая директория, индекс и репозиторий

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

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

Давайте создадим в рабочей директории какой-нибудь файл и запустим команду git status :

Да, git не записал (не закоммитил) изменения, сделанные в рабочей директории, напрямую в репозиторий.

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

Рабочая директория находится в точно таком же состоянии, как индекс и репозиторий.

При выполнении git commit текущая ветка master начинает указывать на только что созданный объект commit.

Внутренняя работа git reset

Мне нравится представлять git reset как команду, которая поворачивает вспять описанный выше процесс (внесение изменений в рабочей директории, добавление их в индекс, а затем сохранение в репозиторий).

Стадия 1. Обновление HEAD — git reset —soft

Если вернуться к нашему примеру, HEAD будет указывать на commit 2, и таким образом new_file.txt не будет частью дерева текущего коммита. Но он будет частью индекса и рабочей директории.

Стадия 2. Обновление индекса — git reset —mixed

В нашем примере это значит, что индекс будет в том же виде, что и commit 2:

Стадия 3. Обновление рабочей директории — git reset —hard

1, а также обновления индекса до (уже обновленного) HEAD, git пойдет еще дальше и обновит рабочую директорию до состояния индекса.

Применительно к нашему примеру это означает, что рабочая директория будет приведена к состоянию индекса, который уже приведен в состояние commit 2:

Собственно, мы вернули весь процесс на этап до создания файла my_file.txt.

Применяем наши знания в реальных сценариях

1. Упс! Я закоммитил что-то по ошибке

Рассмотрим следующий сценарий. Мы создали файл со строкой «This is very importnt», отправили его в стейджинг, а после — в коммит.

А затем — ой! — обнаружили, что в предложении у нас опечатка.

2. Упс! Я сделал коммит не в ту ветку, а эти изменения мне нужны в новой ветке

Со всеми нами такое случалось. Сделал что-то, закоммитил…

О нет, мы сделали коммит в ветку master, а надо было создать новую и затем сделать пул-реквест.

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

Собственно, от желаемого состояния нас отделяют три изменения.

Мы можем достичь желаемого положения в три шага:

Во-вторых, нужно сделать так, чтобы master указывала на предыдущий коммит (иными словами, на HEAD

3. Упс! Я отправил коммит не в ту ветку, а он мне нужен в другой (уже существующей) ветке

В этом случае мы проходим те же шаги, что и в предыдущем сценарии. Мы проделали какую-то работу и закоммитили изменения…

Давайте снова изобразим текущее и желаемое положение:

У нас опять же есть три отличия.

Теперь наше положение следующее:

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

1 — теперь мы вернулись к изначальному состоянию этой ветки.

Таким образом мы достигли желаемого положения:

Итоги

Также мы применили свои новые знания для решения жизненных задач.

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

Источник

Шпаргалка по Git. Решение основных проблем

Восстановление накопленных изменений

В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:

Если существует более одного накопления, найти нужное можно с помощью команды:

git stash list затем можно применить его, воспользовавшись его индексом:

Необходимо учитывать, что отсчёт индексов ведётся от нуля.

Восстановление удалённого тега

В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:

После того, как нужный тег найден, его следует восстановить:

Восстановление удалённого файла

Если вы случайно удалили файл, его можно быстро восстановить:

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

Восстановление удалённой ветки

С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:

После этого восстановить удалённую ветку можно будет вот такой командой:

Изменение сообщения коммита перед его отправкой

Сообщение можно изменить и напрямую с помощью команды

Изменение сообщения коммита после его отправки

Предупреждение: подобная насильная перезапись может привести к потери коммитов из внешней ветки, если с ней давно не было синхронизации, соблюдайте осторожность.

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

Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.

— теперь нужно писать только git st

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

Теперь алиас git logme будет выводить все наши коммиты.

Коммит в неправильную ветку

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

А затем переключиться к оригинальной ветке:

. и «откатиться» до последнего коммита, который нужно сохранить.

Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.

Предупреждение: Убедитесь в том, что никто не отправлял коммиты в оригинальную ветку во время выполнения вышеописанных процедур, в противном случае эти изменения будут потеряны!

Обновление конкретного подмодуля

Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:

Откат к конкретному коммиту в истории

Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:

Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.

Отмена коммита до публикации изменений

Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.

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

Чтобы сохранить сообщение коммита, наберите: :

Отмена коммита после отправки его в master-репозиторий

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

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

Простая отмена последнего коммита:

Отмена локальных изменений файлов

Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:

Кроме того, можно восстановить конкретный путь к файлу:

Отображение всех коммитов одного файла

Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.

Отображения числа коммитов от каждого участника

Хотите узнать, сколько коммитов сделал каждый участник команды?

Отобразить коммиты, содержащие удалённые файлы

Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:

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

Отсортировать коммиты по автору

Чтобы вывести список коммитов, отфильтрованных по автору, следует воспользоваться следующей командой:

Очистка всех скрытых состояний

Очистить все скрытые состояния можно следующей командой:

Переименование локальной и удалённой ветки

Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:

А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25

А теперь заново публикуем её с новым именем: git push origin hotfix-users

Переименование тега

Чтобы переименовать существующий тег:

Перестать отслеживать существующие файлы

Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:

Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:

и отправить изменения.

Подготовка удалённых файлов

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

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

Поиск конкретного сообщения во всех коммитах

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

Пометить конфликтующий файл, как разрешённый

Чтобы пометить один или несколько конфликтующих файлов, как разрешённые, чтобы их можно было нормально изменять, воспользуйтесь командой:

Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.

Просмотр всех неотправленных коммитов

Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:

Кроме того, можно использовать:

Просмотр старой ревизии файла

Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:

Публикация локальной ветки для удалённого редактирования

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

Теперь они тоже смогут вносить изменения в эту ветку.

Сброс локальной ветки до состояния удалённой

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

Прежде всего нужно получить свежие обновления из удалённой ветки:

А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:

Синхронизировать ветку с master-репозиторием

Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:

А затем осуществляете «перебазирование»:

После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.

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

Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.

Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:

Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>

Совмещение двух и более коммитов

Если есть необходимость в совмещении двух последних коммитов, можно использовать команду

После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитов, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь

Совмещение коммитов по конкретной функции для добавления в ветку релиза

Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.

Ниже представлен пример того, как достичь подобного эффекта:

В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.

Создание новой ветки с изменениями текущей

Часто возникает ситуация, при которой пользователи начинают изменять файлы в ветке, чтобы что-то исправить, и лишь позднее вспоминают, что предварительно не создали новую ветку. К счастью, есть способ сделать это уже в процессе:

Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».

Убрать файл из буфера

Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:

Удаление внешней ветки

Если вы хотите удалить ветку, введите команду:

Удаление неотслеживаемых файлов и папок

Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:

Чтобы в принципе удалить их:

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

Удаление старых веток, стёртых из внешнего репозитория

Если ветка удалена из внешнего репозитория, её также можно стереть из локального репозитория с помощью команды

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

Удаление файла из git с сохранением его локальной копии

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

Без Гита и жизнь не та

Получите практику в Git на курсах HTML Academy. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.

Источник

Раскрытие тайн reset

Три дерева

Разобраться с командами reset и checkout будет проще, если считать, что Git управляет содержимым трёх различных деревьев. Здесь под «деревом» мы понимаем «набор файлов», а не специальную структуру данных. (В некоторых случаях индекс ведет себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.)

В своих обычных операциях Git управляет тремя деревьями:

Снимок последнего коммита, родитель следующего

Снимок следующего намеченного коммита

Указатель HEAD

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

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

Команды cat-file и ls-tree являются «служебными» (plumbing) командами, которые используются внутри системы и не требуются при ежедневной работе, но они помогают нам разобраться, что же происходит на самом деле.

Индекс

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

Технически, индекс не является древовидной структурой, на самом деле, он реализован как сжатый список (flattened manifest) — но для наших целей такого представления будет достаточно.

Рабочий Каталог

Технологический процесс

Основное предназначение Git — это сохранение снимков последовательно улучшающихся состояний вашего проекта, путём управления этими тремя деревьями.

На данном этапе только дерево Рабочего Каталога содержит данные.

Теперь мы хотим закоммитить этот файл, поэтому мы используем git add для копирования содержимого Рабочего Каталога в Индекс.

Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.

Сейчас команда git status не показывает ничего, так как снова все три дерева одинаковые.

Переключение веток и клонирование проходят через похожий процесс. Когда вы переключаетесь (checkout) на ветку, HEAD начинает также указывать на новую ветку, ваш Индекс замещается снимком коммита этой ветки, и затем содержимое Индекса копируется в ваш Рабочий Каталог.

Назначение команды reset

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

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

Шаг 1: Перемещение указателя HEAD

Шаг 2: Обновление Индекса (—mixed)

), выполнение команды также остановится на этом шаге.

Шаг 3: Обновление Рабочего Каталога (—hard)

Резюме

Команда reset в заранее определённом порядке перезаписывает три дерева Git, останавливаясь тогда, когда вы ей скажете:

Делает Рабочий Каталог таким же как и Индекс.

Reset с указанием пути

Перемещает ветку, на которую указывает HEAD (будет пропущено)

Делает Индекс таким же как и HEAD (остановится здесь)

То есть, фактически, она копирует файл file.txt из HEAD в Индекс.

Именно поэтому в выводе git status предлагается использовать такую команду для отмены индексации файла. (Смотрите подробности в Отмена индексации файла.)

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

Давайте посмотрим, как, используя вышеизложенное, сделать кое-что интересное — слияние коммитов.

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

Затем просто снова выполните git commit :

Сравнение с checkout

Без указания пути

Второе важное отличие заключается в том, как эти команды обновляют HEAD. В то время как reset перемещает ветку, на которую указывает HEAD, команда checkout перемещает сам HEAD так, чтобы он указывал на другую ветку.

Итак, в обоих случаях мы перемещаем HEAD на коммит A, но важное отличие состоит в том, как мы это делаем. Команда reset переместит также и ветку, на которую указывает HEAD, а checkout перемещает только сам HEAD.

С указанием пути

Заключение

Ниже приведена памятка того, как эти команды воздействуют на каждое из деревьев. В столбце «HEAD» указывается «REF» если эта команда перемещает ссылку (ветку), на которую HEAD указывает, и «HEAD» если перемещается только сам HEAD. Обратите особое внимание на столбец «Сохранность РК?» — если в нем указано NO, то хорошенько подумайте прежде чем выполнить эту команду.

Источник