Я внес некоторые изменения в файл, который был передан несколько раз как часть группы файлов, но теперь хочу reset/вернуть изменения на него обратно в предыдущую версию.
Я сделал git log
вместе с git diff
, чтобы найти нужный мне вариант, но просто не знаю, как вернуть файл в прежнее состояние в прошлом.
Предполагая, что хеш коммита, который вы хотите, c5f567
:
git checkout c5f567 -- file1/to/restore file2/to/restore
Страница руководства git checkout дает больше информации.
Если вы хотите вернуться к фиксации до c5f567
, добавьте ~1
(работает с любым числом):
git checkout c5f567~1 -- file1/to/restore file2/to/restore
Как примечание, мне всегда было неудобно с этой командой, потому что она использовалась как для обычных вещей (переключение между ветвями), так и для необычных, разрушительных вещей (исключая изменения в рабочем каталоге).
Вы можете быстро просмотреть изменения, внесенные в файл, используя команду diff:
git diff <commit hash> <filename>
Затем, чтобы вернуть конкретный файл этому фиксатору, используйте команду reset:
git reset <commit hash> <filename>
Возможно, вам придется использовать опцию --hard
, если у вас есть локальные модификации.
Хорошим документооборотом для управления путевыми точками является использование тегов для чистоты точек на вашей временной шкале. Я не могу понять ваше последнее предложение, но то, что вам может понадобиться, - это расхождение ветки с предыдущего момента времени. Для этого используйте удобную команду checkout:
git checkout <commit hash>
git checkout -b <new branch name>
Затем вы можете переустановить это против своей основной линии, когда будете готовы объединить эти изменения:
git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>
Вы можете использовать любую ссылку на фиксацию git, включая SHA-1, если это наиболее удобно. Дело в том, что команда выглядит так:
git checkout [commit-ref] -- [filename]
--
, и принятым, который не имеет?
git checkout -- foo
Это будет reset foo
для HEAD. Вы также можете:
git checkout HEAD^ foo
для одной ревизии и т.д.
git checkout -- foo
чтобы избежать ошибок, если foo
- это что-то особенное (например, каталог или файл с именем -f
). В git, если вы не уверены, всегда ставьте перед всеми файлами и каталогами специальный аргумент --
.
--
это не команда git и не специально для git. Это встроенный bash для обозначения конца параметров команды. Вы также можете использовать его со многими другими командами bash.
И чтобы вернуться к последней завершенной версии, которая наиболее часто необходима, вы можете использовать эту более простую команду.
git checkout HEAD file/to/restore
У меня была такая же проблема только сейчас, и я нашел этот ответ проще всего понять (commit-ref
- значение SHA изменения в журнале, который вы хотите отправить назад):
git checkout [commit-ref] [filename]
Это ставит эту старую версию в ваш рабочий каталог, и оттуда вы можете ее зафиксировать, если хотите.
Если вы знаете, сколько коммитов вам нужно вернуться, вы можете использовать:
git checkout master~5 image.png
Предполагается, что вы находитесь в ветке master
, а желаемая версия - 5.
Я думаю, что нашел... от http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
Иногда вы просто хотите вернуться и забыть обо всех изменениях за определенный момент, потому что все они неправы.
Начните с:
$ git log
который показывает вам список последних коммитов и их хэш SHA1.
Затем введите:
$ git reset --hard SHA1_HASH
чтобы восстановить состояние для данной фиксации и стереть все новые записи из записи навсегда.
Это сработало для меня:
git checkout <commit hash> file
Затем зафиксируйте изменение:
git commit -a
Вы должны быть осторожны, когда говорите "откат". Если вы использовали одну версию файла в commit $A, а затем сделали два изменения в двух отдельных коммитах $B и $C (так что вы видите, это третья итерация файла), и если вы скажете "Я хочу вернуться к первому", вы действительно это имеете в виду?
Если вы хотите избавиться от изменений как второй, так и третьей итерации, это очень просто:
$ git checkout $A file
а затем вы фиксируете результат. Команда запрашивает "Я хочу проверить файл из состояния, записанного фиксацией $A".
С другой стороны, то, что вы имели в виду, это избавиться от изменения второй итерации (то есть совершить $B), при сохранении того, что зафиксировал файл $C в файле, вы хотели бы вернуть $B
$ git revert $B
Обратите внимание: кто бы ни создавал commit $B, возможно, не был очень дисциплинирован и мог совершить совершенно несвязанные изменения в одной и той же фиксации, и это возвращение может касаться файлов, отличных от файла, который вы видите, оскорбительные изменения, поэтому вы можете проверить результат тщательно после этого.
Интересно, 'git checkout foo' не будет работать, если рабочая копия находится в каталоге с именем foo; однако, как "w20 > checkout HEAD foo" и "git checkout./foo" будет:
$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo
git checkout -- foo
Здесь rebase
работает:
git checkout <my branch> git rebase master git checkout master git merge <my branch>
Предположим, что у вас есть
---o----o----o----o master \---A----B <my branch>
Первые две команды... совершить git выписка git мастер переустановки
... проверьте ветвь изменений, которые вы хотите применить к ветки master
. Команда rebase
берет коммиты из <my branch>
(которые не найдены в master
) и повторно применяет их к заголовку master
. Другими словами, родительский элемент первого коммита в <my branch>
больше не является предыдущим фиксатором в истории master
, а текущим заголовком master
. Две команды такие же, как:
git rebase master <my branch>
Возможно, было бы легче запомнить эту команду, так как ветки "base" и "modify" явно.
. Конечный результат:
---o----o----o----o master \----A'----B' <my branch>
Последние две команды...
git checkout master
git merge <my branch>
... выполните быстрое слияние для применения всех изменений <my branch>
на master
. Без этого шага фиксация rebase не добавляется к master
. Конечный результат:
---o----o----o----o----A'----B' master, <my branch>
master
и <my branch>
обе ссылки B'
. Кроме того, с этой точки можно безопасно удалить ссылку <my branch>
.
git branch -d <my branch>
git -алиасы, awk и функции оболочки для спасения!
git prevision <N> <filename>
где <N>
- это количество исправлений файла для отката для файла <filename>
.
Например, чтобы проверить немедленную предыдущую ревизию одного файла x/y/z.c
, запустите
git prevision -1 x/y/z.c
Добавьте в свой gitconfig
[alias]
prevision = "!f() { git checkout `git log --oneline $2 | awk -v commit="$1" 'FNR == -commit+1 {print $1}'` $2;} ;f"
Команда в основном
- выполняет
git log
в указанном файле и- выбирает соответствующий идентификатор фиксации в истории файла и
- выполняет
git checkout
идентификатор commit для указанного файла.
По существу, все, что можно было бы сделать вручную в этой ситуации,
завернутый в один красивый, эффективный git -alias - git-prevision
Мне нужно подключить EasyGit здесь, который является оберткой, чтобы сделать git более доступным для новичков, не запутывая опытных пользователей. Одна из вещей, которые она делает, - дает больше значений git revert
. В этом случае вы просто скажете:
eg revert foo/bar foo/baz
eg revert --in REVISON -- FILENAME
. --in
важно. Для пользователей Windows: откройте git bash. Выполнить echo %PATH
. Первый путь должен быть в вашем пользовательском каталоге, заканчивающемся bin
. Создайте этот путь. Хранить, например, там. Назовите это eg
. Не например eg.txt
.
Первая Reset Голова для целевого файла
git reset HEAD path_to_file
Вторая проверка этого файла
git checkout -- path_to_file
В случае, если вы хотите вернуть файл в предыдущую фиксацию (и файл, который вы хотите вернуть уже зафиксирован), вы можете использовать
git checkout HEAD^1 path/to/file
или
git checkout HEAD~1 path/to/file
Затем просто выполните этап и зафиксируйте "новую" версию.
Вооружившись знаниями о том, что в случае слияния commit может иметь двух родителей, вы должны знать, что HEAD ^ 1 является первым родителем, а HEAD ~ 1 является вторым родителем.
Либо будет работать, если в дереве есть только один родитель.
Обратите внимание, что git checkout ./foo
и git checkout HEAD ./foo
не точно одно и то же; пример:
$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A
(Второй add
обрабатывает файл в индексе, но он не получает
совершено.)
git checkout ./foo
означает возврат пути ./foo
к индексу ;
добавление HEAD
инструктирует Git вернуть этот путь в индекс к его
HEAD
до этого.
Здесь много предложений, большинство из них в духе git checkout $revision -- $file
. Пара неясных альтернатив:
git show $revision:$file > $file
А также, я часто использую это только для того, чтобы временно увидеть конкретную версию:
git show $revision:$file
или же
git show $revision:$file | vim -R -
(OBS: $file
должен начинаться с префикса ./
если это относительный путь для git show $revision:$file
to work)
И тем более странно
git archive $revision $file | tar -x0 > $file
Чтобы перейти к предыдущей версии файла фиксации, получите номер фиксации, скажем, eb917a1 то
git checkout eb917a1 YourFileName
Если вам просто нужно вернуться к последней зарегистрированной версии
git reset HEAD YourFileName
git checkout YourFileName
Это приведет вас к последнему зафиксированному состоянию файла
Для меня ни один ответ не казался действительно ясным, и поэтому я хотел бы добавить мой, который кажется супер простым.
У меня есть commit abc1
, и после него я сделал несколько (или одну модификацию) файла file.txt
.
Теперь скажите, что я что-то испортил в файле file.txt
, и я хочу вернуться к предыдущему commit abc1
.
1. git checkout file.txt
: это приведет к удалению локальных изменений, если они вам не нужны.
2. git checkout abc1 file.txt
: это приведет ваш файл к вашей желаемой версии
3. git commit -m "Restored file.txt to version abc1"
: это приведет к вашей реверсии.
git push
: это приведет все в удаленный репозиторийМежду шагами 2 и 3, конечно, вы можете сделать git status
, чтобы понять, что происходит. Обычно вы должны видеть, что file.txt
уже добавлен, и поэтому нет необходимости в git add
.
git checkout ref | commitHash - filePath
например.
git checkout HEAD~5 -- foo.bar
or
git checkout 048ee28 -- foo.bar
Многие ответы здесь требуют использовать git reset ... <file>
или git checkout ... <file>
, но при этом вы потеряете все изменения в <file>
, совершенные после коммита, который вы хотите вернуть.
Если вы хотите отменить изменения только от одного фиксации только в одном файле, как это сделал бы git revert
, но только для одного файла (или, скажем, подмножества файлов фиксации), я предлагаю использовать как git diff
, так и git apply
как это (с <sha>
= хеш коммита, который вы хотите вернуть):
git diff <sha>^ <sha> path/to/file.ext | git apply -R
В принципе, он сначала сгенерирует патч, соответствующий изменениям, которые вы хотите вернуть, а затем отмените применение патча, чтобы отбросить эти изменения.
Конечно, он не работает, если ревертированные строки были изменены любым фиксацией между <sha1>
и HEAD
(конфликтом).
Используйте git log
для получения хеш-ключа для конкретной версии, а затем используйте git checkout <hashkey>
Примечание. Не забудьте ввести хэш перед последним. Последний хэш указывает текущую позицию (HEAD) и ничего не меняет.
Очевидно, кому-то нужно написать понятную книгу на git или git, чтобы ее лучше объяснить в документации. Столкнувшись с этой же проблемой, я догадался, что
cd <working copy>
git revert master
отменяет последнее совершение, которое, как представляется, делает.
Ян
Если вы делаете неправильный файл в ваших последних коммитах, следуйте инструкциям:
Вы можете сделать это в 4 этапа:
Что нужно набрать в своем терминале:
git revert <commit_hash>
git reset HEAD~1
git add <file_i_want_to_revert>
&& git commit -m 'reverting file'
git checkout.
удачи
git-revert
действует только на весь репо, поэтому чтобы компенсировать это, мы должны отменить все остальное.
git revert <hash>
Вернет заданную фиксацию. Похоже, вы думаете, что git revert
влияет только на последнее совершение.
Это не решит вашу проблему, если вы хотите отменить изменение в определенном файле и что commit изменился больше, чем этот файл.
Это очень простой шаг. Извлеките файл с идентификатором фиксации, который мы хотим, здесь один идентификатор фиксации ранее, а затем просто выполните команду git commitmend, и все готово.
# git checkout <previous commit_id> <file_name>
# git commit --amend
Это очень удобно. Если мы хотим вывести какой-либо файл с любым идентификатором предыдущей фиксации в верхней части фиксации, мы можем легко это сделать.
Если вы используете Git Extensions и хотите вернуться к родительскому фиксации для файла, вы можете выбрать фиксацию, содержащую изменения, которые хотите вернуть, затем выбрать вкладку "Diff" в деталях щелкните правой кнопкой мыши файл, который вы хотите вернуть, затем Reset файл на "....", затем "A" (родительский)
Вот мой путь.
a) В Android Studio откройте файл.
b) git → Показать историю, найти предыдущую фиксацию, к которой я хочу вернуться. Получите commit_id (т.е. Commit hash).
c) git checkout commit_id file_path
git checkout Last_Stable_commit_Number - fileName
2.Git вернуть файл в определенную ветку
git checkout branchName_Which_Has_stable_Commit fileName
--cached
при проверкеgit diff
. ссылка на сайт