Git удалить коммит: Как отменить или удалить коммит в Git

Git для начинающих. Часть 8. Как отменить коммит в git?

Рассмотрим довольно важный вопрос: как удалить коммит в git? Начнем с вопроса отмены изменений в рабочей директории, после этого перейдем к репозиторию. В рамках этой темы изучим вопросы удаления и замены последнего коммита, работу с отдельными файлами и использование команд git revert и git reset.

Отмена изменений в файлах в рабочей директории

Если вы сделали какие-то изменения в файле и хотите вернуть предыдущий вариант, то для этого следует обратиться к репозиторию и взять из него файл, с которым вы работаете. Таким образом, в вашу рабочую директорию будет скопирован файл из репозитория с заменой. Например, вы работаете с файлом main.c и внесли в него какие-то изменения. Для того чтобы  вернуться к предыдущей версии (последней отправленной в репозиторий)  воспользуйтесь командой git checkout.

> git checkout -- main.c

Ключ “- -” означает, что нас интересует файл в текущем бранче (ветке).

Отмена коммитов в git

Работа с последним коммитом

Для демонстранции возможностей git создадим новый каталог и инициализируем в нем репозиторий.

> git init

Добавим в каталог файл main.c.

> touch main.c

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

> git add main.c
> git commit -m "first commit"
[master (root-commit) 86f1495] first commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 main.c

Внесем изменения в файл.

> echo "// main.c file" > main.c

И сделаем еще один коммит.

> git add main.c
> git commit -m "second commit"
[master d142679] second commit
 1 file changed, 1 insertion(+)

В репозиторий, на данный момент, было сделано два коммита.

> git log --oneline
d142679 second commit
86f1495 first commit

Теперь удалим последний коммит и вместо него отправим другой. Предварительно изменим содержимое файла main.c.

> echo "// author: Writer" > main.c

Отправим изменения в репозиторий с заметой последнего коммита.

> git add main.c
> git commit --amend -m "third commit"
> git log --oneline
18411fd third commit
86f1495 first commit

Как вы можете видеть: из репозитория пропал коммит с id=d142679, вместо него теперь коммит с id=18411fd.

Отмена изменений в файле в выбранном коммите

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

> echo "// Some text 1" > main.c
> git add main.c
> git commit -m "fourth commit"
[master dcf7253 ] fourth commit
 1 file changed, 1 insertion(+), 1 deletion(-)

> echo "// Some text 2" > main.c
> git add main.c
> git commit -m "fifth commit"
[master 7f2eb3a ] fifth commit
 1 file changed, 1 insertion(+), 1 deletion(-)

> git log --oneline
7f2eb3a fifth commit
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Помните, что в предыдущем разделе мы поменяли коммит с сообщением “second commit” на “third commit”, поэтому он идет сразу после “first commit”.

Представим ситуацию, что два последних коммита были неправильными, и нам нужно вернуться к версии 18411fd и внести изменения именно в нее. В нашем примере, мы работаем только с одним файлом, но в реальном проекте файлов будет много, и после коммитов, в рамках которых вы внесли изменения в интересующий вас файл, может быть ещё довольно много коммитов, фиксирующих изменения в других файлах. Просто так взять и удалить коммиты из середины ветки не получится – это нарушит связность, что идет в разрез с идеологией git. Одни из возможных вариантов – это получить версию файла из нужного нам коммита, внести в него изменения и сделать новый коммит. Для начала посмотрим на содержимое файла main.c из последнего, на текущий момент, коммита.

> git checkout main.c
> cat main.c
// Some text 2

Для просмотра содержимого файла в коммите с id=18411fd воспользуемся правилами работы с tree-ish (об этом подробно написано здесь)

> git show 18411fd:main.c
// author: Writer

Переместим в рабочую директорию файл main.c из репозитория с коммитом id=18411fd.

> git checkout 18411fd -- main.c
> cat main.c
// author: Writer

Мы видим, что теперь содержимое файла main.c соответствует тому, что было на момент создания коммита с  id=18411fd. Сделаем коммит в репозиторий и в сообщении укажем, что он отменяет два предыдущих.

> git add main.c
> git commit -m "return main.c from third commit"
[master cffc5ad] return main.c from third commit
 1 file changed, 1 insertion(+), 1 deletion(-)

> git log --oneline
cffc5ad return main.c from third commit
7f2eb3a fifth commit
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Таким образом мы вернулись к предыдущей версии файла main.c и при этом сохранили всю историю изменений.

Использование git revert для быстрой отмены изменений

Рассмотрим ещё одни способ отмены коммитов, на этот раз воспользуемся командой git revert.

В нашем примере, отменим коммит с id=cffc5ad. После того как вы введете команду git revert (см. ниже), система git выдаст сообщение в текстовом редакторе, если вы согласны с тем, что будет написано в открытом файле, то просто сохраните его и закройте. В результате изменения будут применены, и автоматически сформируется и отправится в репозиторий коммит.

> git revert cffc5ad 
[master 81499da] Revert "return main.c from third commit"
 1 file changed, 1 insertion(+), 1 deletion(-)

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

> git config core.editor "notepad.exe"

Обратите внимание, что в этом случае будут изменены настройки для текущего репозитория. Более подробно об изменении настроек смотрите в “Git для начинающих. Часть 3. Настройка Git”

Проверим, применялась ли настройка.

> git config core.editor
notepad.exe

Посмотрим на список коммитов в репозитории.

> git log --oneline
81499da Revert "return main.c from third commit"
cffc5ad return main.c from third commit
7f2eb3a fifth commit
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Содержимое файла вернулось к тому, что было сделано в рамках коммита с id=7f2eb3a. 

> cat main.c
// Some text 2

> git show 7f2eb3a:main.c
// Some text 2

Отмена группы коммитов

ВНИМАНИЕ! Используйте эту команду очень аккуратно!

Если вы не знакомы с концепцией указателя HEAD, то обязательно прочитайте статью “Git для начинающих. Часть 7. Поговорим о HEAD и tree-ish“. HEAD указывает на коммит в репозитории, с которого будет вестись дальнейшая запись, т.е. на родителя следующего коммита. Существует три опции, которые можно использовать с командой git reset для изменения положения HEAD и управления состоянием stage и рабочей директории, сейчас мы все это подробно разберем.

Удаление коммитов из репозитория (без изменения рабочей директории) (ключ –soft)

Для изменения положения указателя HEAD в репозитории, без оказания влияния рабочую директорию (в stage, при этом, будет зафиксированно отличие рабочей директории от репозитория), используйте ключ –soft. Посмотрим ещё раз на наш репозиторий.

> git log --oneline
81499da Revert "return main.c from third commit"
cffc5ad return main.c from third commit
7f2eb3a fifth commit
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Содержимое файла main.с в рабочей директории.

> cat main.c
// Some text 2

Содержимое файла main.с в репозитории.

> git show HEAD:main.c
// Some text 2

Теперь переместим HEAD в репозитории на коммит с id=dcf7253.

> git reset --soft dcf7253

Получим следующий список коммитов.

> git log --oneline
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Содержимое файла main.c в репозитории выглядит так.

> git show HEAD:main.c
// Some text 1

В рабочей директории файл main.c остался прежним (эти изменения отправлены в stage).

> cat main.c
// Some text 2

Для того, чтобы зафиксировать в репозитории последнее состояние файла main.c сделаем коммит.

> git commit -m "soft reset example"
[master db1a8b0] soft reset example
 1 file changed, 1 insertion(+), 1 deletion(-)

Посмотрим на список коммитов.

> git log --oneline
db1a8b0 soft reset example
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

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

81499da Revert "return main.c from third commit"
cffc5ad return main.c from third commit
7f2eb3a fifth commit

Удаление коммитов из репозитория и очистка stage (без изменения рабочей директории) (ключ –mixed)

Если использовать команду git reset с аргументом –mixed, то в репозитории указатель HEAD переместится на нужный коммит, а также будет сброшено содержимое stage. Отменим последний коммит.

> git reset --mixed dcf7253
Unstaged changes after reset:
M       main.c

В результате изменилось содержимое репозитория.

> git log --oneline
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Содержимое файла main.c в последнем коммите выглядит так.

> git show HEAD:main.c
// Some text 1

Файл main.c в рабочей директории не изменился.

> cat main.c
// Some text 2

Отправим изменения вначале в stage, а потом в репозиторий.

> git add main.c
> git commit -m "mixed reset example"
[master ab4ef00] mixed reset example
 1 file changed, 1 insertion(+), 1 deletion(-)

Удаление коммитов из репозитория, очистка stage и внесение изменений в  рабочую директорию (ключ –hard)

Если вы воспользуетесь ключем –hard, то обратного пути уже не будет. Вы не сможете восстановить данные из рабочей директории. Все компоненты git (репозиторий, stage и рабочая директория) будут приведены к одному виду в соответствии с коммитом, на который будет перенесен указатель HEAD.

Текущее содержимое репозитория выглядит так.

> git log --oneline
ab4ef00 mixed reset example
dcf7253 fourth commit
18411fd third commit
86f1495 first commit

Посмотрим на содержимое файла main.c в каталоге и репозитории.

> cat main.c
// Some text 2
> git show HEAD:main.c
// Some text 2

Содержимое файлов идентично.

Удалим все коммиты до самого первого с id=86f1495.

> git reset --hard 86f1495
HEAD is now at 86f1495 first commit

Содержимое репозитория.

> git log --oneline
86f1495 first commit

Состояние рабочей директории и stage.

> git status
On branch master
nothing to commit, working tree clean

Содержимое файла main.c в репозитории и в рабочей директории.

> cat main.c
> git show HEAD:main.c

Файл main.c пуст.

Т.к. мы воспользовались командой git reset с ключем –hard, то восстановить прежнее состояние нам не получится.

БУДЬТЕ ОЧЕНЬ АККУРАТНЫ С ЭТОЙ КОМАНДОЙ!

Отличный курс по git  делают ребята из GeekBrains, найдите в разделе “Курсы” курс “Git. Быстрый старт”, он бесплатный!

<<< Часть 8. Добавление, удаление и переименование файлов в репозитории

17. Удаление коммитов из ветки

Цели

• Научиться удалять самые последние коммиты из ветки

Revert из предыдущего раздела является мощной командой, которая позволяет отменить любые коммиты в репозиторий. Однако, и оригинальный и «отмененный» коммиты видны в истории ветки (при использовании команды git log).

Часто мы делаем коммит, и сразу понимаем, что это была ошибка. Было бы неплохо иметь команду «возврата», которая позволила бы нам сделать вид, что неправильного коммита никогда и не было. Команда «возврата» даже предотвратила бы появление нежелательного коммита в истории git log.

01 Команда reset

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

При получении ссылки на коммит (т.е. хэш, ветка или имя тега), команда reset…

1. Перепишет текущую ветку, чтобы она указывала на нужный коммит
2. Опционально сбросит буферную зону для соответствия с указанным коммитом
3. Опционально сбросит рабочий каталог для соответствия с указанным коммитом

02 Проверьте нашу историю

Давайте сделаем быструю проверку нашей истории коммитов.

Выполните:

git hist

Результат:

$ git hist
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (HEAD, master) [Alexander Shvets]
* 846b90c 2011-03-09 | Oops, we didn't want this commit [Alexander Shvets]
* fa3c141 2011-03-09 | Added HTML header (v1) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h2 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Мы видим, что два последних коммита в этой ветке — «Oops» и «Revert Oops». Давайте удалим их с помощью сброса.

03 Для начала отметьте эту ветку

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

Выполните:

git tag oops

04 Сброс коммитов к предшествующим коммиту Oops

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

Выполните:

git reset --hard v1
git hist

Результат:

$ git reset --hard v1
HEAD is now at fa3c141 Added HTML header
$ git hist
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h2 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Наша ветка master теперь указывает на коммит v1, а коммитов Oops и Revert Oops в ветке уже нет. Параметр --hard указывает, что рабочий каталог должен быть обновлен в соответствии с новым head ветки.

05 Ничего никогда не теряется

Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.

Выполните:

git hist --all

Результат:

$ git hist --all
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (oops) [Alexander Shvets]
* 846b90c 2011-03-09 | Oops, we didn't want this commit [Alexander Shvets]
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h2 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

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

06 Опасность сброса

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

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

Как отменить последний Git-коммит

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

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

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

Выполните:

git revert HEAD

Команда revert означает возврат состояния к HEAD – последнему коммиту в ветке.

Появится следующее сообщение:

Если открытие редактора не нужно, к исходной команде добавляется --no-edit. Смотрим, как это работает:

git revert HEAD --no-edit

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

git log

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

Проверьте Git-статус следующей командой:

git status

Если нужно откатиться к конкретному коммиту, вместо HEAD вписывается его хеш или тег (можно посмотреть в логах/истории). Иногда такая отмена невозможна из-за конфликтов, то есть произошли изменения, которые Git не может отменить. Увидеть конфликтный файл для дальнейшего решения проблемы поможет git status.

Как видите, revert оставляет «следы» в истории ветки, а иногда нужно подобную ошибку скрыть. К возможностям reset относятся:

1. Переписывание текущей ветки, которая будет указывать на необходимый коммит.
2. Сброс буферной зоны (опционально).
3. Сброс рабочего каталога (опционально).

Для начала отметьте нужную ветку:

git tag oops

Теперь выполните сброс до коммита oops:

git reset --hard t1

Посмотрите историю:

git hist

Однако все равно ничто не теряется. Запустите команду отображения всех коммитов:

git hist --all

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

16. Отмена коммитов

Цели

• Научиться отменять коммиты в локальный репозиторий.

01 Отмена коммитов

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

Мы отменим коммит путем создания нового коммита, отменяющего нежелательные изменения.

02 Измените файл и сделайте коммит

Измените файл hello.html на следующий.

Файл: hello.html

<html>
  <head>
  </head>
  <body>
    <h2>Hello, World!</h2>
    <!-- This is an unwanted but committed change -->
  </body>
</html>

Выполните:

git add hello.html
git commit -m "Oops, we didn't want this commit"

03 Сделайте коммит с новыми изменениями, отменяющими предыдущие

Чтобы отменить коммит, нам необходимо сделать коммит, который удаляет изменения, сохраненные нежелательным коммитом.

Выполните:

git revert HEAD

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

Результат:

$ git revert HEAD --no-edit
[master 45fa96b] Revert "Oops, we didn't want this commit"
 1 files changed, 1 insertions(+), 1 deletions(-)

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

Примечание: Команду --no-edit можно проигнорировать. Она была необходима для генерации выходных данных без открытия редактора.

04 Проверьте лог

Проверка лога показывает нежелательные и отмененные коммиты в наш репозиторий.

Выполните:

git hist

Результат:

$ git hist
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (HEAD, master) [Alexander Shvets]
* 846b90c 2011-03-09 | Oops, we didn't want this commit [Alexander Shvets]
* fa3c141 2011-03-09 | Added HTML header (v1) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h2 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Эта техника будет работать с любым коммитом (хотя, возможно, возникнут конфликты). Она безопасна в использовании даже в публичных ветках удаленных репозиториев.

05 Далее

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

Как убрать из Git-репозитория файлы с конфиденциальной информацией

Файлы проиндексированы, написано сообщение коммита, данные отправлены на сервер… И вдруг хочется повернуть время вспять. В коммит попал файл, которого там быть не должно. Когда такое случается, приходит время обращаться к поисковику.

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

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

Удаление файлов с конфиденциальной информацией из Git-репозитория (изображение большого размера)

Минимизация ущерба

Итак, вы случайно закоммитили файл с конфиденциальной информацией. Назовём этот файл .env. Сразу после того, как это случилось, надо задать себе пару вопросов:

• Отправлен ли коммит в удалённый репозиторий?
• Является ли удалённый репозиторий общедоступным?

▍Коммит пока не отправлен в удалённый репозиторий

Если вы пока не отправили коммит в репозиторий, то, в общем-то, возникшая ситуация никакой угрозы не несёт. Для того чтобы всё исправить, достаточно просто вернуться к предыдущему коммиту:

git reset HEAD^ --soft

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

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

git rm .env --cached
git commit --amend

Параметр --amend можно использовать только для работы с самым свежим коммитом. Если вы, после неудачного коммита, добавили ещё несколько, воспользуйтесь такой командой:

git rebase -i HEAD~{на сколько коммитов нужно вернуться?}

Это позволит исправить неправильный коммит и поможет не потерять изменения, внесённые в проект остальными коммитами.

▍Коммит отправлен в удалённый репозиторий

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

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

Если вы отправили в репозиторий, после проблемного коммита, и другие коммиты, это не помешает вам убрать файлы с конфиденциальными данными из истории Git, воспользовавшись командой git filter-branch или инструментом BFG Repo-Cleaner.

Вот пример использования git filter-branch:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all

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

• Вы меняете историю Git. Если на текущее состояние репозитория полагаются другие люди, если от этого состояния зависят какие-то ветки того же репозитория, его форки, открытые PR, то это нарушит их работу. В подобных случаях относитесь к репозиторию как к общедоступному и постарайтесь не вносить изменения в его историю.
• Вам нужно будет очистить кеш. Вам понадобится обратиться в службу поддержки платформы, на которой хранится ваш репозиторий, и попросить очистить его кеш. Несмотря на то, что вы исправили проблемный коммит или переписали историю репозитория, старый коммит, содержащий конфиденциальные данные, останется в кеше. Для того чтобы к нему обратиться, нужно будет знать его ID, но к нему можно будет получить доступ до тех пор, пока кеш не очистят.

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

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

Даже если вы удалили эти данные из репозитория, вы ничего не сможете сделать с ботами и с форками репозитория. Как же поступить?

• Деактивируйте все ключи или пароли. Это надо сделать в первую очередь. После того, как вы деактивируете ключи, конфиденциальные сведения, ушедшие в общий доступ, оказываются бесполезными.
• Настройте файл .gitignore. Сделайте в .gitignore записи о файлах с конфиденциальной информацией для того чтобы Git не отслеживал бы состояние этих файлов.
• Подготовьте коммит, в котором нет файлов с конфиденциальной информацией.
• Отправьте изменения в репозиторий, снабдите коммит пояснениями о возникшей ситуации. Не пытайтесь скрыть ошибку. Все программисты, работающие над проектом, включая вас, по достоинству оценят наличие в репозитории коммита с разъяснениями ситуации и с описанием того, что именно было исправлено с помощью данного коммита.

Рекомендации по хранению конфиденциальных файлов в проектах, в которых для контроля версий применяется Git

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

▍Храните секретные данные в файле .env (или в другом подобном файле)

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

Ещё одно преимущество такого подхода заключается в том, что так у вас будет доступ ко всем ключам через глобальную переменную process.

▍Используйте, если это возможно, ключи API

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

▍Храните ключи API, пользуясь средствами вашего инструмента для сборки проектов

Ключи API обычно нужны при сборке приложений. Инструменты для сборки проектов, вроде Netlify, позволяют держать ключи в защищённых хранилищах. Такие ключи автоматически внедряются в приложение с использованием глобальной переменной process.
Управление переменными окружения

▍Добавьте запись о файле .env в файл .gitignore

Сделайте так, чтобы Git не отслеживал бы файлы, содержащие конфиденциальную информацию.

▍Подготовьте шаблонный файл .env.template

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

▍Не меняйте историю Git в удалённых репозиториях

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

Итоги

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

А вам случалось отправлять в общедоступный репозиторий что-то такое, что туда попадать не должно?

Изменение коммитов в Git / Хабр

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

Изменение последнего коммита

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

git add .

Затем закоммитить изменения с параметром —amend (amend /əˈmɛnd/ — вносить поправки, исправлять, улучшать):

git commit --amend

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

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

git commit --amend -m "Новое название"

Изменение НЕ последнего коммита

Тут чуть посложнее, сделайте для начала два коммита, в моем примере они будут называться С1 и С2:

Для начала выполняем:

git rebase --interactive 
# короткая версия: git rebase -i

Откроется редактор, в котором вы можете указать что хотите сделать:

Как видите, git rebase -i может послужить когда нужно

• r reword переименовать коммит
• e edit изменить коммит
• s squash склеить два или больше коммитов (squash /skwɒʃ/ — втиснуть, сжимать, тыква 🙂 )

Рядом с коммитом С1 вместо pick впишите e для редактирования коммита или r для переименования. Сохранив файл, вы увидите подсказку от Git:

Разберемся подробнее что произошло. Мы переместились на коммит С1, «спрыгнув» с ветки master. Это можно проверить, запустив:

git branch

В ответ получим:

* (no branch, rebasing master)
  master

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

git add .

и коммитим с параметром --amend:

git commit --amend

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

git rebase --continue

Тем самым мы возвратимся на ветку master с измененным коммитом, что и требовалось.

Пост получился короткий и, надеюсь, ясный. Commit early, commit often.

Удалить коммиты из ветки в Git — git

Я хотел бы знать, как удалить коммит.

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

Я читаю git help, и я думаю, что команда, которую я должен использовать, это git reset --hard HEAD . Это правильно?

git

git-rebase

git-reset

Поделиться

Источник

hap497    

27 августа 2009 в 03:39

25 Ответов

3672

Осторожно: git reset --hard удалит ваши изменения рабочего каталога . Перед выполнением этой команды обязательно сохраните все локальные изменения, которые вы хотите сохранить.

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

git reset --hard HEAD~1

HEAD~1 означает фиксацию перед главой.

Или вы можете посмотреть на выходные данные git log, найти идентификатор фиксации для фиксации, к которой вы хотите создать резервную копию, и затем сделать это:

git reset --hard <sha1-commit-id>

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

git push origin HEAD --force

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

Если вы уже нажали, может быть, лучше использовать git revert, чтобы создать фиксацию «mirror image», которая отменит изменения. Однако оба коммита будут записаны в журнал.

FYI — git reset --hard HEAD отлично подходит, если вы хотите избавиться от незавершенной работы. Он сбросит вас обратно к самой последней фиксации и сотрет все изменения в вашем рабочем дереве и индексе.

Наконец, если вам нужно найти коммит, который вы «deleted», он обычно присутствует в git reflog , если только вы не собрали мусор в своем репозитории.

Поделиться

gahooa    

27 августа 2009 в 03:44

647

Если вы еще не нажали фиксацию в любом месте, вы можете использовать git rebase -i , чтобы удалить эту фиксацию. Во-первых, выясните, как далеко назад находится эта фиксация (приблизительно). Тогда делать:

git rebase -i HEAD~N

~N означает перебазирование последних коммитов N ( N должно быть числом, например HEAD~10). Затем вы можете отредактировать файл, который представляет вам Git, чтобы удалить нарушающий коммит. При сохранении этого файла Git затем перепишет все следующие коммиты, как если бы тот, который вы удалили, не существовал.

В книге Git есть хороший раздел по ребазингу с картинками и примерами.

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

Поделиться

Greg Hewgill    

27 августа 2009 в 03:51

452

Еще одна возможность-это одна из моих личных любимых команд:

git rebase -i <commit>~1

Это приведет к запуску ребаза в интерактивном режиме -i в точке непосредственно перед фиксацией, которую вы хотите ударить. Редактор начнет выводить список всех коммитов с тех пор. Удалите строку, содержащую фиксацию, которую вы хотите стереть, и сохраните файл. Rebase будет выполнять rest работы, удаляя только эту фиксацию и воспроизводя все остальные обратно в журнал.

Поделиться

1800 INFORMATION    

27 августа 2009 в 03:49

315

Я добавляю этот ответ, потому что не понимаю, почему любой, кто только что пытался совершить работу, хотел бы удалить всю эту работу из-за какой-то ошибки с использованием Git!

Если вы хотите сохранить свою работу и просто ‘undo’, что команда commit (вы поймали перед нажатием на репо):

git reset --soft HEAD~1

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

Поделиться

Rob    

15 октября 2012 в 18:17

74

Удаление всего совершить

git rebase -p --onto SHA^ SHA

Очевидно, замените «SHA» ссылкой, от которой вы хотите избавиться. Символ » ^ » в этой команде является буквальным.

http://sethrobertson.github.io/GitFixUm/fixup.html

Поделиться

raittes    

31 августа 2015 в 19:36

51

Если вы не публиковали изменения, чтобы удалить последнюю фиксацию, вы можете сделать это

$ git reset --hard HEAD^

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

Если вы уже опубликовали to-be-deleted commit, используйте git revert

$ git revert HEAD

Поделиться

Jakub Narębski    

27 августа 2009 в 10:47

35

git reset --hard commitId

git push <origin> <branch> --force

PS: CommitId относится к тому, к которому вы хотите вернуться

Поделиться

sun34    

16 октября 2014 в 09:51

31

Насильственно Изменить Историю

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

git rebase -i HEAD~<number of commits to go back>, так что git rebase -i HEAD~5 , если вы хотите увидеть последние пять коммитов.

Затем в текстовом редакторе измените слово pick на drop рядом с каждым коммитом, который вы хотите удалить. Сохраните и закройте редактор. Вуаля!

Аддитивно Изменить Историю

Попробовать git revert <commit hash> . Revert создаст новый коммит, который отменяет определенный коммит.

Поделиться

IliasT    

15 июня 2017 в 23:01

29

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

git reset HEAD~1

Это вернет ваш репозиторий в его состояние до того, как команды git add разместят файлы. Ваши изменения будут находиться в вашем рабочем каталоге. HEAD~1 относится к фиксации ниже текущей вершины ветви.

Если вы хотите раскомментировать N коммитов, но сохранить изменения кода в вашем рабочем каталоге:

git reset HEAD~N

Если вы хотите избавиться от последней фиксации и не хотите сохранять изменения кода, Вы можете выполнить сброс «hard».

git reset --hard HEAD~1

Аналогично, если вы хотите отбросить последние N коммитов и не хотите сохранять изменения кода:

git reset --hard HEAD~N

Поделиться

Anurag-Sharma    

31 мая 2014 в 07:19

27

Допустим, мы хотим удалить коммиты 2 & 4 из РЕПО.

commit 0 : b3d92c5
commit 1 : 2c6a45b
commit 2 : <any_hash>
commit 3 : 77b9b82
commit 4 : <any_hash>

Примечание: Вы должны иметь права администратора над РЕПО , так как вы используете --hard и -f .

• git checkout b3d92c5 проверка последнего пригодного к использованию коммита.
• git checkout -b repair создайте новую ветвь для работы.
• git cherry-pick 77b9b82 выполните команду commit 3.
• git cherry-pick 2c6a45b выполните команду commit 1.
• git checkout master мастер оформления заказа.
• git reset --hard b3d92c5 сбросить мастер до последнего пригодного для использования коммита.
• git merge repair объедините нашу новую ветвь с мастером.
• git push -f origin master нажмите master для удаленного РЕПО.

Поделиться

tk_    

05 сентября 2017 в 07:19

18

git rebase -i HEAD~2

Здесь ‘2’ — это количество коммитов, которые вы хотите перебазировать.

'git rebase -i HEAD`

если вы хотите перебазировать все коммиты.

Тогда вы сможете выбрать один из этих вариантов.

p, pick = use commit

r, reword = use commit, but edit the commit message

e, edit = use commit, but stop for amending

s, squash = use commit, but meld into previous commit

f, fixup = like "squash", but discard this commit's log message

x, exec = run command (the rest of the line) using shell

d, drop = remove commit

Эти строки могут быть переупорядочены; они выполняются сверху вниз.
Если вы удалите здесь строку, то фиксация будет потеряна.
Однако, если вы удалите все, перебазирование будет прервано.
Обратите внимание, что пустые коммиты закомментированы

Вы можете просто удалить эту фиксацию, используя опцию «d» или удалив строку, в которой есть ваша фиксация.

Поделиться

Siva Praveen    

18 мая 2016 в 23:39

14

Чтобы удалить локальную ветку использовать

git reset --hard HEAD~1

Для удаления в удаленной ветке используйте

git push origin HEAD --force

Поделиться

thestar    

28 августа 2014 в 16:06

9

Вот еще один способ сделать это:

Проверьте ветку, которую вы хотите вернуть, а затем сбросьте свою локальную рабочую копию обратно в фиксацию, которую вы хотите сделать последней на удаленном сервере (все, что после этого будет сделано, будет удалено). Для этого в SourceTree я щелкнул правой кнопкой мыши и выбрал «Reset BRANCHNAME to this commit». Я думаю, что командная строка-это:

git reset --hard COMMIT_ID

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

Затем перейдите в локальный каталог вашего репозитория и выполните эту команду:

git -c diff.mnemonicprefix=false -c core.quotepath=false \
push -v -f --tags REPOSITORY_NAME BRANCHNAME:BRANCHNAME

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

Поделиться

CommaToast    

13 мая 2013 в 17:20

9

Ошибка:

I git rebase -i --root ‘ ed my branch, невежественно думая, что я мог бы перефразировать первый коммит, отличающийся от master (представление GitHub для Windows по умолчанию-это сравнение с master, скрывающее его полноту).

Я отрастил бороду в Кремниевой долине, пока 900 + коммитов загружались в Sublime. Выйдя без каких — либо изменений, я зарядил свою батарею, а затем продолжил бриться, поскольку все 900+ индивидуальных коммитов небрежно перебазировались-сбросив свои коммиты до настоящего времени.

Решив победить Git и сохранить исходные времена, я удалил этот локальный репозиторий и повторно клонировал его с пульта дистанционного управления.

Теперь он снова добавил самое последнее ненужное обязательство к мастеру, которое я хотел удалить,поэтому продолжалось так.

Исчерпание возможностей:

Я не хотел git revert -это создало бы дополнительный коммит, давая Git преимущество.

git reset --hard HEAD ничего не сделал, после проверки reflog, последним и единственным HEAD был клон — Git побед.

Чтобы получить самую последнюю версию SHA, я проверил удаленный репозиторий на github.com — minor win.

Подумав, что git reset --hard <SHA> сработал, я обновил другую ветвь до master и 1… 2… пуф! коммит был возвращен-Git побед.

Возвращаясь к мастеру, время попробовать git rebase -i <SHA>, а затем удалить строку… к сожалению, безрезультатно. «Если вы удалите здесь строку, то фиксация будет потеряна«. Ah…glossed над новой функцией троллит n00b в примечаниях к выпуску 2.8.3 .

Решение:

git rebase -i <SHA> потом d, drop = remove commit .

Чтобы проверить, я выехал в другую ветку, и вуаля — никаких скрытых обязательств по извлечению/вытягиванию из Мастера.

when you're trying to learn a new programming language for the first time pic.twitter.com/1l8Gv2TQvn

— Zach Holman (@holman) March 5, 2016

Доброго вам дня.

Поделиться

Leo    

25 мая 2016 в 20:33

8

Все вышеперечисленные команды восстанавливают состояние вашего рабочего дерева и индекса, как они были до совершения фиксации, но не восстанавливают состояние репозитория. Если вы посмотрите на него, фиксация «removed» фактически не удалена, она просто не находится на кончике текущей ветви.

Я думаю, что нет никаких средств для удаления фиксации с помощью фарфоровых команд . Единственный способ-удалить его из журнала и рефлога, а затем выполнить git prune --expire -now .

Поделиться

Angelo Borsotti    

04 октября 2012 в 07:19

7

Если вы просто испортили свой последний коммит (неверное сообщение, забыли добавить некоторые изменения) и хотите исправить его, прежде чем отправлять его в публичное РЕПО, почему бы не использовать:

git commit --amend -m "New message here"

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

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

Вы также можете передать опцию ‘—no-edit ‘вместо’ — m’, Если вы предпочитаете использовать сообщение предыдущей фиксации.

Доктора:
http://git-scm.com/docs/git-commit.html

Поделиться

Pwnrar    

26 мая 2014 в 23:24

7

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

git revert GIT_COMMIT_HASH

введите сообщение, объясняющее, почему вы возвращаетесь, а затем:

git push  

Когда вы выдаете git log вы увидите, как «wrong» совершить и восстановить сообщения журнала.

Поделиться

Paulo Fidalgo    

07 января 2015 в 15:13

6

Источник: https://gist.github.com/sagarjethi/c07723b2f4fa74ad8bdf229166cf79d8

Удалить последний коммит

Например ваш последний коммит

git push origin +aa61ab32^: master

Теперь вы хотите удалить эту фиксацию тогда простой способ сделать это следующий

Шаги

1. Сначала сбросьте ветвь к родительскому элементу текущей фиксации

2. Сила-подтолкните его к пульту дистанционного управления.

git reset HEAD^ --hard

git push origin -f

Для конкретной фиксации вы хотите сбросить следующее

git reset bb676878^ --hard

git push origin -f

Поделиться

sagar jethi    

22 июня 2018 в 13:40

5

Если вы уже нажали, сначала найдите коммит, который вы хотите сделать в HEAD ($GIT_COMMIT_HASH_HERE) , а затем выполните следующее:

git reset --hard $GIT_COMMIT_HASH_HERE
git push origin HEAD --force

Затем каждое место РЕПО было клонировано, запускайте:

git reset --hard origin/master

Поделиться

Justin    

30 января 2017 в 00:25

5

То, что я делаю обычно, когда я совершаю и толкаю (если кто-то толкнул его совершить это решить проблему):

git reset --hard HEAD~1

git push -f origin

надеюсь это поможет

Поделиться

Chris Sim    

14 июня 2017 в 09:22

4

Сброс на локальную ветку

git reset --hard HEAD~<Number of commit> So git reset --hard HEAD~3

Принудительный толчок к началу координат

git push -f origin

Поделиться

Ashish Singh    

29 мая 2018 в 07:38

3

Сделайте резервную копию вашего кода в папке temp. Следующая команда будет сброшена так же, как сервер.

git reset --hard HEAD
git clean -f
git pull

Если вы хотите сохранить свои изменения и удалить последние фиксации

git reset --soft HEAD^
git pull

Поделиться

Lava Sangeetham    

14 июля 2016 в 11:25

2

Я уже давил на него. Нужно вернуть некоторые коммиты обратно удаленно.
Перепробовали много вариаций,
но только это от Джастина через git Буша прекрасно работает для меня:

git reset --hard $GIT_COMMIT_HASH_HERE
git push origin HEAD --force

Поделиться

Serg Burlaka    

08 февраля 2019 в 21:29

1

git сброс —жесткий

git начало толчка HEAD —сила

Если один или несколько коммитов помечены, сначала удалите тег(ы). В противном случае помеченная фиксация не удаляется.

Поделиться

BillChan    

24 июля 2015 в 14:45

1

Как вы можете видеть на приведенном выше изображении, я хочу удалить revert» test change 2 » commit(SHA1 ID: 015b5220c50e3dfbb1063f23789d92ae1d3481a2 (вы можете получить SHA1 ID с помощью команды gitk в git bash)).

Для этого я могу использовать(все ниже команды работают только на локальном уровне. вам нужно нажать после удаления):

1. git reset --hard 515b5220c50e3dfbb1063f23789d92ae1d3481a2 //it резервное копирование вас к этому коммиту (SHA1 ID из test change 4 commit is 515b5220c50e3dfbb1063f23789d92ae1d3481a2 )
2. git reset --hard HEAD~1 // это резервное копирование вас перед одним коммитом.
3. git reset --hard HEAD^ // чтобы удалить последнюю фиксацию из git

после удаления:

Поделиться

ankit    

03 июля 2018 в 06:51

Похожие вопросы:

удалить коммиты (навсегда) из истории git

Я хотел бы навсегда удалить указанные коммиты из всей истории репозитория git. Я видел эту тему , в которой рекомендуется следующее: git reset —hard HEAD~4 git push origin HEAD —force Это…

Как отменить коммиты в git

Я совершил дважды и еще не нажал. Как я могу отменить это, хотя я ничего не делал. Я всегда думал, что это сбросит его: git checkout master но это не сработало. Я также погуглил и нашел этот пост:…

Удалить самые старые коммиты из репозитория git

Возможный Дубликат : Полностью удалить (старые) git коммитов из истории git очень полезно для ночных снимков клиентских веб-сайтов. Знание всего (php + mysqldump + загрузка пользовательских файлов)…

Как удалить все коммиты из уже нажатой ветки в git?

Работая над проектом с большим количеством членов команды, мы сейчас пытаемся отшлифовать наши способы работы. В настоящее время вся работа ведется в ветке integration , которая была отделена от…

Удалить пустые коммиты в git

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

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

Мне нужно найти способ удалить все коммиты, кроме последнего (самого последнего) 159 из ветки, используя Git. Я также согласен с созданием новой ветви и перемещением в нее последних 159, если это…

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

Есть ли способ увидеть с помощью git log или какой-либо другой команды только те коммиты, которые были добавлены после создания ветки? usage: git log [<options>] [<since>..<until>]…

Есть ли способ исключить коммиты из ветки в git?

Я ищу способ исключить коммиты из ветки. Допустим, у меня есть мастер ветви, который я нажимаю на рабочий сервер. Но у меня есть коммиты, которые я не хочу нажимать на сервер. Есть ли способ…

Git: удалить все коммиты из запроса pull

У меня есть запрос на вытягивание, где я добавил коммиты. Однако я хочу удалить все коммиты из этого PR и начать с нуля. Где я могу добавить свои коммиты снова? Я использовал git rebase , но у меня…

git-перемещение определенных коммитов из ветки разработки в ветку функций

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

Это откроет последнюю фиксацию, но оставит все ваши изменения в файлах нетронутыми.

Если вам нужно удалить не только последнюю фиксацию, вы можете использовать два метода. Первый использует rebase , что позволит вам удалить одну или несколько последовательных коммитов, другой — cherry-pick , который позволяет вам удалять непоследовательные коммиты.

Пример журнала git

Использование Rebase

Используя приведенный выше журнал git, мы хотим удалить следующие коммиты; 2 и 3 (ae45fab и 77b9b82).Поскольку это последовательные коммиты, мы можем использовать rebase.

git rebase --onto <имя ветки> ~ <номер первой удаляемой фиксации> <имя ветки> ~ <первая сохраняемая фиксация> <имя ветки>

, например, чтобы удалить коммиты 2 и 3 выше

git rebase --onto repair ~ 3 ремонта ~ 1 ремонт

Используя Cherry Pick

Шаг 1: Найдите фиксацию перед фиксацией, которую вы хотите удалить git log

Шаг 2: Checkout, который фиксирует git checkout

Шаг 3: Создайте новую ветку, используя текущую фиксацию проверки git checkout -b <новая ветка>

Шаг 4: Теперь вам нужно добавить фиксацию после удаленной фиксации git cherry-pick

Шаг 5: Теперь повторите шаг 4 для всех остальных коммитов, которые вы хотите сохранить.

Шаг 6: После того, как все коммиты были добавлены в вашу новую ветку и выполнены. Убедитесь, что все в правильном состоянии и работает должным образом. Дважды проверьте, все ли выполнено: git status

Шаг 7: Перейти на сломанную ветку git checkout <сломанная ветка>

Шаг 8: Теперь выполните полный сброс сломанной ветки до фиксации, предшествующей той, которую вы хотите удалить git reset --hard

Шаг 9: Слияние фиксированной ветки с этой веткой git merge <имя ветки>

Шаг 10: Вернуть объединенные изменения в исходную точку. ВНИМАНИЕ: это перезапишет удаленное репо! git push --force origin <имя ветки>

Вы можете выполнить процесс без создания новой ветви, заменив Шаг 2 и 3 на Шаг 8 , а затем не выполнять Шаги 7 и 9.

Пример

Допустим, мы хотим удалить коммиты 2 и 4 из репо.

1. git checkout b3d92c5 Извлечь последний использованный коммит.
2. git checkout -b repair Создать новую ветку для работы.
3. git cherry-pick 77b9b82 Выполнить фиксацию 3.
4. git cherry-pick 2c6a45b Выполнить фиксацию 1.
5. git checkout master checkout master.
6. git reset --hard b3d92c5 Сбросить мастер до последней использованной фиксации.
7. git merge repair Слить нашу новую ветку с мастером.
8. git push --hard origin master Отправить мастер в удаленное репо.

Заключительное примечание

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

Наконец-то не забудьте быть осторожным и удачи!

.

git — Как полностью удалить коммит из GitHub?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.

Страница не найдена · GitHub Pages

Страница не найдена · GitHub Pages

Файл не найден

Сайт, настроенный по этому адресу, не
содержать запрошенный файл.

Если это ваш сайт, убедитесь, что регистр имени файла соответствует URL-адресу.
Для корневых URL (например, http://example.com/ ) вы должны предоставить
index.html файл.

Прочтите полную документацию
для получения дополнительной информации об использовании GitHub Pages .

.

git — Как удалить коммиты из запроса на перенос

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.