Я клонировал репозиторий git определенного проекта. Могу ли я вернуть файлы в исходное состояние и при просмотре файлов перейти к ревизии 2, 3, 4 ... самой последней? Я хотел бы получить обзор того, как развивался проект.
Перейти к конкретной версии
Ответы (8)
Перед выполнением этой команды имейте в виду, что она оставит вас в статусе отсоединенной головы.
Используйте git checkout <sha1>, чтобы проверить конкретную фиксацию.
Где <sha1> - уникальный номер фиксации, который вы можете получить с помощью git log
Вот несколько вариантов после того, как вы перейдете в статус отсоединенной головы:
- Скопируйте файлы или внесите необходимые изменения в папку за пределами вашей папки git, проверьте ветку, где они вам нужны
git checkout <existingBranch>, и замените файлы - Создайте новый локальный филиал
git checkout -b <new_branch_name> <sha1>
person
Marcelo Cantos
schedule
24.09.2011
И есть ли способ узнать, в какой ревизии этот проект? Я попытался проверить первый коммит с его sha1, и я хотел бы подтвердить, что я действительно там, и каков будет sha1 следующего коммита.
- person xralf; 24.09.2011
Вы можете сделать это
git log -n1. Но если git checkout не потерпит неудачу, это пустая трата усилий.
- person Marcelo Cantos; 25.09.2011
Оно работает. Пришлось использовать полный sha1 (а не частичный). А если я захочу поставить проект на вторую ревизию?
git log теперь показывает только первую фиксацию, могу ли я узнать sha1 следующей фиксации?
- person xralf; 25.09.2011
Вам нужно использовать только достаточное количество sha1, чтобы гарантировать уникальность. Возможно, вам попалось неудачное совпадение. Git не имеет представления о следующем коммите; история - это DAG, все стрелки которого направлены назад. Вы должны запустить
git log --oneline и вставить вывод в текстовый файл для справки (сокращенные суммы sha1, которые он предоставляет, гарантированно будут уникальными). Другой вариант, если ваша история линейна, - это выяснить, сколько коммитов было от первого коммита до master, и использовать git checkout master~543 (если есть 543 коммита), затем git checkout master~542 и т. Д.
- person Marcelo Cantos; 25.09.2011
Сейчас я нахожусь в первой ревизии, поэтому, когда я запускаю
git log --oneline, я вижу только одну фиксацию, следует ли мне снова клонировать репозиторий? Затем запустите git log --oneline > commits.txt, а затем используйте файл commits.txt в качестве ссылки? Разве это не громоздко?
- person xralf; 25.09.2011
Нет, просто
git log --oneline master.
- person Marcelo Cantos; 25.09.2011
Примечание. При этом каталоги не удаляются, поэтому вы можете увидеть пустые каталоги, связанные с версией 7, даже если файлы принадлежат версии 5. Это может быть удивительно.
- person Nicolas Raoul; 21.08.2012
и как вернуться к текущей фиксации из git checkout ‹sha1›?
- person アレックス; 28.06.2015
@AlexanderSupertramp Оформить заказ в филиале.
- person Marcelo Cantos; 29.06.2015
@MarceloCantos, я хотел сказать, после проверки, как можно вернуться в основную ветку или вернуться к фиксации, в которой они были изначально? Я бы предположил, что это
git checkout master или какая-то другая ветка, в зависимости от того, где вы работаете?
- person Charlie Parker; 07.03.2016
Ах, теперь я вижу; Я потерял подразумеваемую запятую. Да, верно, git checkout можно использовать для перехода к любой фиксации, которую вы хотите, по идентификатору, тегу, ветке или любому из ряда других методов для указания фиксации.
- person Marcelo Cantos; 07.03.2016
нашел так много сложных ответов на это в других темах. Тем не менее, это простое утверждение делает все. ;) Спасибо
- person Prachi; 19.04.2016
Вероятно, вам следует добавить, что делать, когда
error: pathspec '866e452bdb859' did not match any file(s) known to git встречается в действительной фиксации. Удивительный GitHub может его найти, а местный Git - нет.
- person jww; 13.11.2017
что здесь
<sha1>?
- person manas; 17.05.2018
После оформления заказа вы также можете вернуться к последней версии, как описано здесь: stackoverflow.com/questions/5772192/
- person Den-Jason; 28.08.2019
@ Den-Jason, по этому вопросу много материалов. Что именно вы имеете в виду? В любом случае вернуться к последней версии так же просто, как
git checkout -.
- person Marcelo Cantos; 31.08.2019
@MarceloCantos, это ответ Даниэля Алексюка. Материал
git rev-parse, предоставленный Крисом Джонсеном, тоже был полезен.
- person Den-Jason; 02.09.2019
Означает ли это, что он проверит ветку, в которой этот sha был первоначально зафиксирован, а также перенесет состояние извлеченной ветки в эту конкретную фиксацию?
- person jxramos; 18.10.2019
git checkout -b <new_branch_name> <sha1>: чтобы проверить фиксацию в ветке.
- person Loganathan; 16.07.2020
Если команда git не видит тот коммит (shat1), который вы пытаетесь оформить, то есть: отправленный кем-то другим на GitHub, вам может потребоваться выполнить
git fetch <origin or other remote location >, чтобы обновить ваши локальные версии. Кроме того, после проверки вы можете сделать git checkout -b <new branch name>, чтобы создать из него рабочую / функциональную ветку.
- person G-Man; 07.10.2020
Чтобы перейти к определенной версии / фиксации, выполните следующие команды. ХЭШ-КОД, который можно получить от git log --oneline -n 10
git reset --hard HASH-CODE
Примечание. После сброса до определенной версии / фиксации вы можете запустить git pull --rebase, если хотите вернуть все отмененные фиксации.
person
J4cK
schedule
26.06.2016
Обратите внимание, что
reset не просто проверяет конкретную точку на графике, он также перемещает вашу текущую проверенную ветку.
- person Liam; 03.07.2019
Также с
reset все ваши ожидающие изменения отменяются.
- person WilliamKF; 14.09.2019
Флаг --hard удалит любые коммиты после указанного хэша ... возможно, вы захотите добавить сюда этот небольшой кусочек. Я уверен, что люди потеряли историю и задавались вопросом, почему.
- person Urasquirrel; 13.02.2020
git pull --rebase работает, только если у вас есть пульт для репо и он обновлен.
- person Keith Thompson; 14.02.2020
Вы можете получить графическое представление истории проекта с помощью таких инструментов, как gitk. Просто беги:
gitk --all
Если вы хотите проверить конкретную ветку:
git checkout <branch name>
Для конкретной фиксации используйте хэш SHA1 вместо имени ветки. (См. Treeishes в Книге сообщества Git, которая является Хорошее прочтение, чтобы увидеть другие варианты навигации по дереву.)
git log также имеет целый набор опций для отображения подробной или сводной истории.
Я не знаю простого способа продвинуться вперед в истории коммитов. Проекты с линейной историей, вероятно, не так уж и распространены. Идея «ревизии», как у SVN или CVS, не очень хорошо отображается в Git.
person
Mat
schedule
24.09.2011
Имейте в виду: git не будет лгать вам, предоставляя вам единую линейную историю проекта. Это если только проект не развивался таким образом.
- person Andres Jaan Tack; 24.09.2011
Двигаться вперед логически бессмысленно (даже в линейной истории), поскольку фиксация не ссылается на будущее. В лучшем случае вы можете идентифицировать все коммиты, у которых рассматриваемая фиксация является родительской. Имейте в виду, что движение назад тоже не является тривиальным упражнением из-за слияний.
- person Marcelo Cantos; 25.09.2011
@MarceloCantos Ну, это не совсем так.
git log -p -m --first-parent --reverse действительно хорошо покажет вам линейную и точную основную историю изменений с самого начала, с отображением изменений из объединенной истории, сведенными в единую разницу.
- person jthill; 23.10.2020
Используя ключ SHA1 коммита, вы можете сделать следующее:
Сначала найдите фиксацию, которую вы хотите для определенного файла:
git log -n <# commits> <file-name>Это, на основе вашего
<# commits>, сгенерирует список коммитов для определенного файла.СОВЕТ: если вы не уверены, какой коммит ищете, хороший способ узнать - использовать следующую команду:
git diff <commit-SHA1>..HEAD <file-name>. Эта команда покажет разницу между текущей версией фиксации и предыдущей версией фиксации для конкретного файла.ПРИМЕЧАНИЕ: ключ SHA1 фиксации форматируется в списке
git log -nкак:
совершить
<SHA1 id>
Во-вторых, проверьте желаемую версию:
Если вы нашли желаемый коммит / версию, просто используйте команду:
git checkout <desired-SHA1> <file-name>Это поместит указанную вами версию файла в промежуточную область. Чтобы вынуть его из области подготовки, просто используйте команду:
reset HEAD <file-name>
Чтобы вернуться к тому месту, где указан удаленный репозиторий, просто используйте команду: git checkout HEAD <file-name>
person
Wizard
schedule
16.05.2016
Я был в ситуации, когда у нас была основная ветка, а затем другая ветка с именем 17.0, а внутри этого 17.0 был хеш фиксации не сказать «XYZ». И заказчику дается сборка до этой ревизии XYZ. Теперь мы обнаружили ошибку, которую необходимо решить для этого клиента. Поэтому нам нужно создать отдельную ветку для этого клиента до хэша «xyz». Вот как я это сделал.
Сначала я создал папку с этим именем клиента на своем локальном компьютере. Скажите, что имя клиента - «AAA», когда эта папка будет создана, введите следующую команду внутри этой папки:
- git init
- git clone. После этой команды вы попадете в главную ветку. Так что переключитесь на желаемую ветку
- git checkout 17.0. Откроется ветка, в которой находится ваша фиксация.
- git checkout. Это займет ваше хранилище до фиксации хэша. Посмотрите имя вашей ветки, в которой он был изменен на хэш-код фиксации. Теперь дайте имя ветки этому хешу
- git branch ABC. Это создаст новую ветку на вашем локальном компьютере.
- git checkout ABC
- git push origin ABC. Эта ветка будет перемещена в удаленный репозиторий и будет создана ветка на сервере git. Вы сделали.
person
ashish
schedule
15.01.2019
Один из способов - создать все коммиты, когда-либо сделанные для исправлений. проверьте исходную фиксацию, а затем примените исправления по порядку после прочтения.
используйте git format-patch <initial revision>, а затем git checkout <initial revision>. у вас должна получиться куча файлов в вашем директоре, начинающаяся с четырех цифр, которые являются исправлениями.
когда вы закончите читать свою ревизию, просто сделайте git apply <filename>, который должен выглядеть как git apply 0001-*, и посчитайте.
Но мне действительно интересно, почему бы вам просто не захотеть вместо этого просто прочитать сами патчи? Пожалуйста, опубликуйте это в своих комментариях, потому что мне любопытно.
руководство git также дает мне это:
git show next~10:Documentation/READMEПоказывает содержимое файла Documentation / README в том виде, в каком оно было текущим в 10-м последнем коммите следующей ветки.
вы также можете взглянуть на git blame filename, который дает вам список, в котором каждая строка связана с хешем коммита + автором.
person
Alexander Oh
schedule
24.09.2011
Чтобы перейти к конкретному зафиксированному коду, вам понадобится хэш-код этого фиксации. Вы можете получить этот хэш-код двумя способами:
- Получите его из своей учетной записи github / gitlab / bitbucket. (Он указан в URL-адресе вашего коммита, например: github.com/user/my_project/commit/<▪commit_hash_code), или вы можете
git logи проверьте свои недавние коммиты в этой ветке. Он покажет вам хэш-код вашего коммита и сообщение, которое вы оставили, когда коммитили свой код. Просто скопируйте и сделайтеgit checkout commit_hash_code
После перехода к этому коду, если вы хотите поработать с ним и внести изменения, вам следует создать другую ветку с git checkout -b <new-branch-name>, иначе изменения не будут сохранены.
person
ihojmanb
schedule
17.02.2020
Чтобы проверить фиксацию (nb вы смотрите в прошлое!).
- git checkout "commmitHash"
Чтобы грубо перезапустить из фиксации и удалить те более поздние ветки, которые вы, вероятно, испортили.
- git reset --hard "commmitHash"
person
Jeremy
schedule
12.05.2020
