В то время, когда я пишу это, есть два предыдущих ответа. Каждый упоминает способ сделать то, что вы просите; но какой-то контекст отсутствует, это важно, если вы решаете, какой из них использовать.
Предполагаемый способ отменить изменения от одного коммита в git - это git revert <commit> этот коммит. Как объясняет Чепнер, это создаст новый коммит, который перевернет «патч» из целевого коммита. Аргумент <commit> может быть идентификатором фиксации (хеш-значение, уникальное для целевого коммита) или выражением, указывающим на фиксацию (например, HEAD~2 - что означает «вернуться назад 2 из текущего извлеченного коммита»). в вашем примере).
Обратите внимание, что если изменение коммитов 3 или 4 совпадает с изменением от 2, возврат может создать конфликты, которые должны быть разрешены так же, как конфликт слияния. Кроме того, иногда взаимодействие между git revert и коммитом слияния может вызывать проблемы - но это может иметь значение, только если то, что вы отменяете, является слиянием, или, может быть, это коммит, изменения которого уже присутствуют в более позднем слиянии , Если вы выполняете поиск по запросу «отменить слияние» или что-то подобное, вы должны найти существующие ответы, детализирующие эти проблемы (если они возникнут).
Причина, по которой люди иногда отказываются от этого решения, заключается в том, что они не хотят, чтобы их история показывала то, что они теперь воспринимают как свои ошибки. Я скажу, что объективно это не должно быть приоритетом, но есть альтернативы, которые удаляют целевой коммит из истории ... за плату.
Эти альтернативы в совокупности называются переписанными историями. Если история является общей, они могут перевести репо в состояние, которое вызывает проблемы у других пользователей, до тех пор, пока они не выполнят очистку, и если они выполнят очистку неправильно, то это отменит изменение и вернет коммит 2 обратно в Поэтому вы должны убедиться, что все пользователи репо находятся в курсе того, что вы делаете.
Кроме того, переписывание истории почти всегда рискует создать нарушенные коммиты. Это происходит потому, что вы переписываете коммиты 3 и 4 автоматически, создавая состояния кода, которые никогда не тестировались. Поскольку 4 - это новый «наконечник ветви», возможно, вы его протестируете; но если вы не вернетесь к тесту 3, это может стать историческим перерывом, который может помешать дальнейшему устранению неполадок (например, с git bisect).
Команды типа git rebase -i или git filter-branch могут использоваться для перезаписи истории, но вы должны убедиться, что разбираетесь в вышеперечисленных проблемах, прежде чем решите использовать их таким образом. Я рекомендую прочесть раздел «восстановление из исходной версии» в документации git rebase; это относится к истории, переписывает в целом.