Как удалить коммит в удаленном репозитории?
Сделал коммит. Не заметил как в него попала пара сотен МБт дерьмища. Потом запушил и тут я обнаружил свой косяк. Подскажите, как в удаленном и локальном репозитории удалить последний коммит с сохранением изменений в рабочей дирректории?
git reset —hard HEAD
1 неподходит, т.к. возвращает меня к комиту 3х месячной давности! Нужно удалить коммит, но чтобы все изменения в рабочей директории сохранились! Спасибо!
Чем не устраивает —soft?
1. удаляешь коммит локально (например, через git rebase -i)
2. git push -f origin branchname
Это банальный и частый вопрос, ответ на который находится за пару минут в гугле.
reset без —hard. —soft/—mixed на выбор. Далее вычищаешь всё ненужно, commit, push -f
. и нет проблем синхронизации.
Смотри-ка, сколько в трэде любителей push —force!
. и есть огромные проблемы с размером репозитория!
в него попала пара сотен МБт дерьмища
или git commit —amend
Через git rm удалить всё ненужное.
Потом git commit —amend, чтобы ранее добавленное и свежеудалённое аннигилировались.
Потом push —force, чтобы перезаписать последний коммит.
Profit!
А как ещё ты предлагаешь удалять часть истории?
В сабжевом случае хорошо подходит это. В том и цимес же, что историю на remote удолять не надо )
+1, сам так делаю, когда накосячу 🙂
Не заметил как в него попала пара сотен МБт дерьмища
Кстати, ТС, а как это случилось? Убогий gitignore?
Каким образом это подходит, если при этом подходе до скончания времен при любом git clone будет тянутся
Во-первых, вопрос именно о том, как её удалить.
Во-вторых, почему не надо-то? Мастер не стоит, но пока это моя бранча — что хочу, то и ворочу.
пока это моя бранча — что хочу, то и ворочу.
Даже если твой бранч уже смержили в мастер?
Не так уж и много + clone не каждый день/неделя/месяц.
А так да, на это внимания не обратил
Вот здесь не понял. С чего ты взял, что это не общая ветка?
Лучше перезапись последнего коммита с push —force в remote, чем мусор на несколько сотен мегабайт в репозитории, который поди <10МБ всего весит.
И за убожество вида revet ‘my shit commit’ в истории тоже надо линчевать.
И за убожество вида revet ‘my shit commit’ в истории тоже надо линчевать
Линчевать много за что можно, но иногда выбора нет. К тому же, смотря на сколько
В случае тонких ошибок полезно это в репе оставить, в назидание, так сказать. К сабжу это не относится, но там по-другому можно повернуть: какого хера gitignore не заюзали? А скорее всего — заюзали, но там шаблонов подходящих не было(на все случаи не напасёшься). Было бы неплохо иметь, скажем gitaccept, указывая какие файлы _отслеживать_, а не какие игнорировать. Через gitignore тоже можно, но там костыльно — сомневаюсь, что пригодно для продакшена. Сколько здесь кандидатур на линчевание?)
Из зол вида «сотни МБ хлама в БД до скончания веков» и «перезапись последнего запушенного коммита» — первая куда как больше.
Я очень сильно сомневаюсь, что у ТС огромный и оверпопулярный репозиторий, который форкают каждый день и каждый час отправляют в него PR’ы. А потому этот —force скорее всего никто кроме TC и не заметит.
Шпаргалка по Git. Решение основных проблем
В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:
Если существует более одного накопления, найти нужное можно с помощью команды:
git stash list затем можно применить его, воспользовавшись его индексом:
Необходимо учитывать, что отсчёт индексов ведётся от нуля.
Восстановление удалённого тега
В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:
После того, как нужный тег найден, его следует восстановить:
Восстановление удалённого файла
Если вы случайно удалили файл, его можно быстро восстановить:
Если требуется восстановить файл из конкретной временной точки истории коммитов, следует узнать хеш нужного коммита и запустить команду:
Восстановление удалённой ветки
С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:
После этого восстановить удалённую ветку можно будет вот такой командой:
Изменение сообщения коммита перед его отправкой
Изменить сообщение коммита можно с помощью команды git commit —amend , она откроет редактор, в котором можно будет внести необходимые поправки в последнее сообщение.
Сообщение можно изменить и напрямую с помощью команды
Изменение сообщения коммита после его отправки
В данном случае процесс занимает два шага. Сначала нужно изменить сообщение с помощью комманды git commit —amend , а затем перезаписать историю коммитов локальной ветки: git push <remote> <branch> —force
Предупреждение: подобная насильная перезапись может привести к потери коммитов из внешней ветки, если с ней давно не было синхронизации, соблюдайте осторожность.
Использование алиасов команд в командной строке
Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.
— теперь нужно писать только git st
Можно пойти дальше и присвоить алиасы более сложным командам:
Теперь алиас git logme будет выводить все наши коммиты.
Коммит в неправильную ветку
Нужно переключиться на новую ветку, которую вы забыли предварительно создать:
А затем переключиться к оригинальной ветке:
. и «откатиться» до последнего коммита, который нужно сохранить.
Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.
Теперь его нужно сбросить: git reset —hard a31a45c и отправить получившийся результат.
Предупреждение: Убедитесь в том, что никто не отправлял коммиты в оригинальную ветку во время выполнения вышеописанных процедур, в противном случае эти изменения будут потеряны!
Обновление конкретного подмодуля
Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:
Откат к конкретному коммиту в истории
Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:
Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.
Отмена коммита до публикации изменений
Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.
Будьте осторожны используя второй вариант, поскольку изменения ваших локальных файлов будут потеряны.
Чтобы сохранить сообщение коммита, наберите: :
Отмена коммита после отправки его в master-репозиторий
Рассмотрим процедуру возврата одного или нескольких коммитов, которые нужно стереть из удалённой ветки. Обозначить конкретный коммит можно с помощью его хеша:
Отмена только коммита, который является вторым после последнего:
Простая отмена последнего коммита:
Отмена локальных изменений файлов
Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:
Кроме того, можно восстановить конкретный путь к файлу:
Отображение всех коммитов одного файла
Если вы хотите просмотреть все коммиты с изменениями конкретного файла, воспользуйтесь командой git log —follow -p — myfile
Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.
Если опустить опцию -p, то система выведет только сообщения коммитов, но не их содержимое.
Отображения числа коммитов от каждого участника
Хотите узнать, сколько коммитов сделал каждый участник команды?
Эта команда выведет список, отсортированный в порядке убывания количества коммитов: git shortlog -s -n
Отобразить коммиты, содержащие удалённые файлы
Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:
Она покажет список коммитов, в которых удалялись файлы.
Отсортировать коммиты по автору
Чтобы вывести список коммитов, отфильтрованных по автору, следует воспользоваться следующей командой:
Очистка всех скрытых состояний
Очистить все скрытые состояния можно следующей командой:
Переименование локальной и удалённой ветки
Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:
А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25
А теперь заново публикуем её с новым именем: git push origin hotfix-users
Переименование тега
Чтобы переименовать существующий тег:
Перестать отслеживать существующие файлы
Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:
Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:
и отправить изменения.
Подготовка удалённых файлов
Чтобы подготовить к коммиту файлы и папки, которые были удалены локально, можно использовать специальную команду:
Если требуется подготовить только используемый в данный момент путь, воспользуйтесь командой
Поиск конкретного сообщения во всех коммитах
Чтобы найти конкретный текст сообщения коммита, соответствующий регулярному выражению, нужно воспользоваться командой
Пометить конфликтующий файл, как разрешённый
Чтобы пометить один или несколько конфликтующих файлов, как разрешённые, чтобы их можно было нормально изменять, воспользуйтесь командой:
Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.
Просмотр всех неотправленных коммитов
Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:
Кроме того, можно использовать:
Просмотр старой ревизии файла
Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:
Публикация локальной ветки для удалённого редактирования
Если вы создали локальную ветку, и хотите, чтобы другие пользователи могли с ней работать, воспользуйтесь командой:
Теперь они тоже смогут вносить изменения в эту ветку.
Сброс локальной ветки до состояния удалённой
В том случае, если отсутствуют изменения, которые необходимо сохранить, сбросить локальную ветку до состояния удалённой можно с помощью двух простых команд.
Прежде всего нужно получить свежие обновления из удалённой ветки:
А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:
При наличии коммита, который нужно сохранить, перед сбросом нужно создать новую ветку и произвести коммит: git commit -m «Обновление»
Синхронизировать ветку с master-репозиторием
Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:
А затем осуществляете «перебазирование»:
После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.
Слияние локальных изменений с другой веткой
Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.
Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:
Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>
Совмещение двух и более коммитов
Здесь нам понадобится произвести интерактивное перебазирование. Если перебазирование происходит относительно master-ветки, то начать следует с команды git rebase -i master. Однако, если перебазирование происходит не относительно ветки, то нужно будет перебазироваться относительно HEAD.
Если есть необходимость в совмещении двух последних коммитов, можно использовать команду
После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитов, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь
Совмещение коммитов по конкретной функции для добавления в ветку релиза
Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.
Ниже представлен пример того, как достичь подобного эффекта:
В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.
Создание новой ветки с изменениями текущей
Часто возникает ситуация, при которой пользователи начинают изменять файлы в ветке, чтобы что-то исправить, и лишь позднее вспоминают, что предварительно не создали новую ветку. К счастью, есть способ сделать это уже в процессе:
Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».
Убрать файл из буфера
Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:
Удаление внешней ветки
Если вы хотите удалить ветку, введите команду:
Удаление неотслеживаемых файлов и папок
Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:
Чтобы в принципе удалить их:
Подсказка: чтобы увидеть, какие файлы являются лишними, перед их непосредственным удалением, наберите:
Удаление старых веток, стёртых из внешнего репозитория
Если ветка удалена из внешнего репозитория, её также можно стереть из локального репозитория с помощью команды
Она удалит старую ветку под названием название-удалённой-ветки, которая уже была стёрта из внешнего репозитория, но всё ещё доступна локально в remotes/название-удалённой-ветки.
Удаление файла из git с сохранением его локальной копии
Для того, чтобы удалить файл из git, но сохранить его локально нужно использовать следующую команду:
Без Гита и жизнь не та
Получите практику в Git на курсах HTML Academy. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.
Откат коммитов на GitHub
Небольшая статья, посвященная вопросу отката коммитов в GitHub.
В чем заключается вопрос, собственно? В том, что имеется определенный репозиторий, размещенный на сервере GitHub. У этого удаленного репозитория есть локальная синхронизированная версия на рабочей машине автора. Этот репозиторий изменяется с большей или меньшей периодичностью; все изменения фиксируются соответствующими коммитами.
И вот в один прекрасный момент в репозиторий было внесено изменение, которое затем было закоммичено и отправлено на GitHub. Однако, от этого изменения нужно избавиться — оно ошибочное.
Но как это сделать, если коммит уже находится на GitHub? В интерфейсе сервиса GitHub я не нашел нужной кнопки, чтобы удалять конкретный коммит и тем самым возвращать репозиторий до нужного состояния.
Это потому, что управление коммитами на GitHub производится через локальный репозиторий. Ниже приведу три несложных шага для того, чтобы показать, каким образом это выполняется.
Шаг первый
Первое — необходимо получить список hash-сумм последних коммитов репозитория. Это и понятно — нужно иметь перед собой дерево коммитов, чтобы видеть — куда двигаться. В дереве коммитов hash-суммы являются опорными точками, идентификационными номерами каждого из коммитов:
Ниже показан краткий вывод команды — четыре самых поздних коммита репозитория:
Мне нужно вернуть репозиторий из состояния, описанного в коммите , в состояние, зафиксированное в коммите .
Шаг второй
Для этого я воспользуюсь командой , с ключом . Эта команда мне подходит потому, что я не собираюсь сохранять изменения, зафиксированные в коммите , так как они полностью ошибочны.
Как подробно описывается в статье Отмена изменений в Git, такую задачу можно выполнить командой:
где — начальные 16 символов hash-суммы коммита, на который я хочу “перепрыгнуть”. Полный вид hash-суммы в 40 символов можно не использовать — достаточно 16 символов для надежной идентификации конкретного коммита.
После выполнения этой команды локальный репозиторий будет сброшен к состоянию, зафиксированному в коммите . Другими словами, я избавился от последних ошибочных изменений и вернул репозиторий в предыдущее его состояние.
Однако, это всего лишь половина дела, так как откат коснулся только локального репозитория. В этой статье речь идет прежде всего об удаленном репозитории, размещенном на GitHub. Как добиться внесения аналогичных изменений на GitHub?
Казалось бы — просто! Достаточно выполнить команду:
Но, на самом деле это не получится сделать — Git не позволит это выполнить. По той причине, что на данный момент состояние локального репозитория имеет более раннюю версию, нежели состояние удаленного репозитория.
Вместо этого Git предложит выполнить комнаду , чтобы привести локальный репозиторий к удаленному.
Шаг третий
Чтобы заставить Git выполнить обратную задачу — привести удаленный репозиторий к локальному, необходимо использовать ключ .
То есть, форсировать внесение изменений и тем самым “сказать” Git — синхронизировать удаленный репозиторий с локальным репозиторием несмотря на то, что последний имеет более ранюю версию:
Заключение
Теперь, если проверить состояние удаленного репозитория на сервере GitHub, то увидим, что оно идентично состоянию локального репозитория. Но самое главное — удален последний ошибочный коммит, чего я и добивался.
Что такое БФФ
«Back-end for front-end» — сервис-прослойка между фронтом и бэком, который обращается к микросервисам и собирает из них данные в удобной . … Continue reading