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

Ответ 1

Проблема

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

Решения для опубликованных веток

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

Либо реверт совершает одно за раз, в обратном порядке, либо использует диапазон <first_bad_commit>..<last_bad_commit>. Хэши - это самый простой способ указать диапазон фиксации, но есть и другие обозначения. Например, если вы нажали 5 плохих коммитов, вы можете вернуть их с помощью:

# Revert a series using ancestor notation.
git revert --no-edit dev~5..dev

# Revert a series using commit hashes.
git revert --no-edit ffffffff..12345678

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

См. man 1 git-revert для получения дополнительных параметров и man 7 gitrevisions для разных способов указать, какие коммиты должны быть возвращены.

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

Опасная зона

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

git reset --hard <last_good_commit>
git push --force

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

Ответ 2

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

Не используйте git reset --hard

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

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

git reset --hard <hash>

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

git reset --hard
git push -f

Если вы нажали изменения, и кто-то втянул их в свой чек, вы все равно можете это сделать, но другой член команды /checkout должен будет сотрудничать:

(you) git reset --hard <hash>
(you) git push -f

(them) git fetch
(them) git reset --hard origin/branch

Но, вообще говоря, это превращается в беспорядок. Итак, возвращаясь:

Конец для удаления - это последний

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

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

git log

просто найдите фиксацию перед изменениями и отметьте хеш фиксации. вы можете ограничить доступ к журналу большинством resent, используя флаг -n: git log -n 5

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

git revert  <hash of first borked commit>..HEAD

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

git branch my-new-branch
git checkout my-new-branch
git revert <hash of each revert commit> .

Продолжайте работать в my-new-branch, пока не закончите, а затем объедините его в свою основную ветку развития.

Конец для удаления смешивается с другими коммитами

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

git revert <hash>
git revert <another hash>
..

Затем снова создайте ветку для продолжения работы:

git branch my-new-branch
git checkout my-new-branch
git revert <hash of each revert commit> .

Затем снова взломайте и слейте, когда закончите.

В конце вы должны будете получить историю фиксации, которая выглядит так: my-new-branch

2012-05-28 10:11 AD7six             o [my-new-branch] Revert "Revert "another mistake""
2012-05-28 10:11 AD7six             o Revert "Revert "committing a mistake""
2012-05-28 10:09 AD7six             o [master] Revert "committing a mistake"
2012-05-28 10:09 AD7six             o Revert "another mistake"
2012-05-28 10:08 AD7six             o another mistake
2012-05-28 10:08 AD7six             o committing a mistake
2012-05-28 10:05 Bob                I XYZ nearly works

Лучший способ®

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

Ответ 3

git revert HEAD -m 1

В приведенной выше строке кода. "Последний аргумент представляет"

• 1 - возвращает один коммит. 2 - возвращает последние коммиты. n - возвращает последний n совершает

или

git reset --hard siriwjdd