Git вернуть отдельный файл

Обновлено: 05.07.2024

Я использую git и работаю над основной веткой. В этой ветке есть файл с именем app.js .

У меня есть ветка experiment , в которую я внес кучу изменений и множество коммитов. Теперь я хочу перенести все изменения, сделанные только в app.js из experiment в master ветку.

Как я могу это сделать?

Еще раз не хочу слияния. Я просто хочу перенести все изменения в app.js из ветки experiment в ветку master .

Обновление август 2019 г., Git 2.23

С новым git switch и git restore , это будут:

По умолчанию восстанавливается только рабочее дерево.
Если вы хотите также обновить индекс (то есть восстановить содержимое файла, и добавьте его в индекс одной командой):

Как отмечает Якуб Наребски в комментариях:

Тоже работает, за исключением того, что подробно описано в вопросе SO "Как получить отдельный файл из определенной ревизии в Git?", вам нужно использовать полный путь из корневого каталога репозитория.
Отсюда путь / к / app.js, который использовал Якуб в своем примере.

Как упоминает Frosty в комментарии:

вы получите только самое последнее состояние app.js

Но для git checkout или git show вы можете ссылаться на любую нужную ревизию, как показано в вопросе SO "git checkout версия файла в git gui":

Будет то же самое, если $ FILENAME - это полный путь к версированному файлу.

$REVISION может быть таким, как показано в git rev-parse :

вы также можете сделать это из тайника:

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

Все намного проще, используйте для этого git checkout.

Предположим, ветвь you're on master , чтобы получить ветку app.js from new-feature , выполните следующие действия:

Это принесет вам содержимое желаемого файла. Как всегда, вы можете использовать часть sha1 вместо new-feature должен быть локальным филиалом, а не удаленным.

Это не сработает, если в названии вашей ветки есть точка.

Дополнение к ответам VonC и chhh.

Все о проверке файлов или каталогов в git

1. Как извлечь один или несколько файлов или каталогов из другой ветки или зафиксировать хэш в текущей извлеченной ветке:

См. Также man git checkout .

Если вы не укажете, branch_name автоматически предполагается, что это HEAD , что является вашей самой последней фиксацией ветки, которая в данный момент проверена. Таким образом, вы также можете просто проверить "somefile.c" и перезаписать любые локальные незафиксированные изменения:

2. Дальше: как извлечь любой файл из любой ветки или зафиксировать хэш в любое место на вашем компьютере (ОЧЕНЬ ПОЛЕЗНО!):

Источник, из которого я это узнал: ответ @Jakub Narębski на: git-checkout старая версия файла под новым именем

3. Что делать, если вы находитесь в процессе разрешения изменений git merge , git cherry-pick , git rebase или git revert ?

Что ж, в таком случае вам лучше сделать так:

НЕ заполняйте обычную форму checkout в предыдущем разделе перед этим, если только вы этого не хотите. См. раздел "ПРЕДУПРЕЖДЕНИЕ ПРЕДУПРЕЖДЕНИЕ ПРЕДУПРЕЖДЕНИЕ" в мой ответ здесь: Кто такие "мы" "и кто такие" они "согласно Git?.

РАБОТА С ОШИБКАМИ path does not have our version или path does not have their version :

Если вы когда-нибудь увидите такие ошибки:

. при выполнении приведенных выше команд вам просто нужно сначала git rm эти файлы, а затем снова попробовать команду git checkout --ours или git checkout --theirs . См. Мой ответ здесь для подробного объяснения этих команд, включая форму для автоматического поиска и удаления этих файлов с ошибками: git checkout - часы, когда спецификация файла включает удаленный файл.

4. Что делать, если вы хотите сбросить определенный файл или каталог, чтобы он точно соответствовал состоянию этого файла или каталога в другой фиксации или ветке?

В этом случае git checkout my_branch -- some_file_or_dir НЕ достаточно, потому что если у вас есть файлы в указанном каталоге, которые существуют в вашей текущей разрегистрированной ветке или фиксации, но НЕ существуют в my_branch , тогда вам нужно их нужно удалить локально, но git checkout НЕ удаляет какие-либо файлы, которые существуют локально, но не в указанной фиксации, а только перезаписывает файлы локально их версии из указанного коммита. Итак, также удалить файлы локально, которых там не должно быть, чтобы то, что у вас получилось локально, было точной копией того, что у вас есть на my_branch необходимо сделать следующее:

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

Я сделал git log вместе с git diff чтобы найти ревизию мне нужно, но просто не знаю, как вернуть файл в его прежнее состояние в прошлом.

предполагая, что хэш фиксации вы хотите c5f567 :

The git checkout man страница дает дополнительную информацию.

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

1 (работает с любого номера):

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

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

затем, чтобы вернуть определенный файл к этой фиксации, используйте команду reset:

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

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

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

вы можете использовать любую ссылку на фиксацию git, включая SHA-1, если это наиболее удобно. Дело в том, что команда выглядит так:

git checkout [commit-ref] -- [filename]

это сбросит foo головы. Вы также можете:

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

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

у меня была такая же проблема только сейчас, и я нашел ответ проще всего понять ( commit-ref - это значение SHA изменения в журнале, к которому вы хотите вернуться):

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

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

это предполагает, что вы на master ветвь, и версия, которую вы хотите, - это 5 коммитов назад.

blynn/gitmagic/ch02.html

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

начать с:

$ git log

который показывает вам список последних коммитов и их хэши SHA1.

далее, типа:

$ git reset --hard SHA1_HASH

для восстановления состояния до заданной фиксации и стереть все новые коммиты из записи навсегда.

это сработало для меня:

зафиксировать изменения:

вы должны быть осторожны, когда вы говорите "откат". Если раньше у вас была одна версия файла в commit $A, а затем вы сделали два изменения в двух отдельных коммитах $B и $C (так что вы видите третью итерацию файла), и если вы говорите "Я хочу вернуться к первому", вы действительно это имеете в виду?

Если вы хотите избавиться от изменений как второй, так и третьей итерации, это очень просто:

и затем вы фиксируете результат. Команда спрашивает:"Я хочу проверить файл из состояния, записанного фиксацией $A".

С другой стороны, вы имели в виду, чтобы избавиться от изменения, внесенного второй итерацией (т. е. commit $B), сохраняя при этом то, что commit $C сделал с файлом, вы хотели бы вернуть $B

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

забавно, 'git checkout foo 'не будет работать, если рабочая копия находится в каталоге с именем foo; однако, как' git checkout HEAD foo', так и ' git checkout ./foo ' will:

Перевод статьи «Git Secrets: 7 Commands You Might Not Know».


Photo by Stefan Steinbauer on Unsplash

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

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

Поиск изменений в файле

Быть в курсе всех дел может быть сложно, особенно если над одной кодовой базой работает много людей.

Чтобы разобраться, как именно (а также — когда и кем) был изменен файл, можно воспользоваться старой доброй командой git log с небольшим дополнением:

Использование флага -p дает возможность увидеть собственно изменения как diff-ы (а не только метаданные коммита). Опция --since помогает сузить временные рамки.

Эффектная отмена последнего коммита

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

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

Для этого можно использовать команду git reset с особым набором опций:

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

1 это отличный шорткат, указывающий, что HEAD должен быть переключен на «коммит перед самым последним».

Если хотите узнать больше об отмене изменений, почитать можно здесь.

Определяем, чем отличается файл в другой ветке

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

  • вы в настоящее время находитесь в ветке «feature/login» и…
  • хотите понять, чем файл «myFile.txt» в этой ветке…
  • отличается от версии этого же файла в ветке «develop».

Разницу можно посмотреть при помощи команды git diff с нужными параметрами:

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

Использование switch вместо checkout

Команда git checkout выполняет множество разных функций и используется для решения разных задач. Поэтому сравнительно недавно Git-сообщество решило опубликовать новую команду: git switch . Как следует из имени (англ. switch — переключатель, переключение), эта команда предназначена специально для переключения между ветками:

Как видите, использование команды довольно простое и похожее на применение git checkout . Но switch имеет огромное преимущество в сравнении с checkout : у него нет миллиона других значений и действий.

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

Переключение туда-сюда между двумя ветками

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

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

Использование git restore для отмены локальных изменений

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

Но теперь у нас есть относительно новая команда git restore , предназначенная именно для этой цели. Такая «узкая специализация» отличает ее от checkout и reset , имеющих множество других вариантов использования.

Вот быстрый обзор самых важных вещей, которые можно делать при помощи git restore :

Восстановление произвольной версии файла из истории

Команда git restore предлагает еще одну очень полезную опцию: --source . С ее помощью можно легко восстановить любую предыдущую версию отдельного файла:

Вы просто указываете хэш версии, которую хотите восстановить (и имя файла, конечно).

Если вам нужна помощь в поиске подходящей версии, можете воспользоваться десктопным клиентом Git, например, Tower. Функционал «File History» позволит вам легко просмотреть только изменения, произошедшие в определенном файле, а затем выбрать нужный вариант для восстановления.

Открывайте для себя всю мощь Git

Хотя в наше время Git хорошо всем знаком, большинство людей не углубляются в его изучение и не используют имеющийся функционал по максимуму. Да, вы вполне можете «выжить», зная лишь несколько простых команд вроде commit, push и pull. Но это примерно как водить Ferrari, пользуясь только первой передачей!

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

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

Как сбросить файл к исходному состоянию в коммите?

Для примера рассмотрим локальный репозиторий, который находится под версионным контролем git. В нашем тестовом проекте имеются изменения в содержимом файла second.php, при этом эти изменения еще не подготовлены к добавлению в следующий коммит, а значит файл находится в состоянии not staged. В этом можно убедиться, воспользовавшись командой:


По каким-то причинам изменения в файле second.php нам не нужны, и требуется получить состояние файла, которое было зафиксировано на момент последнего коммита. Сделать это очень просто с помощью команды:


Как сбросить файл к состоянию в коммите, если изменения уже подготовлены командой git add?

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

  • Убрать файл из подготовленного состояния к фиксации в коммите, т.е. перевести файл из состояния staged.
  • Сбросить файл к исходному состоянию.

Для примера рассмотрим ситуацию, когда в нашем локальном репозитории есть файл second.php , в который были внесены изменения и более того эти изменения были подготовлены к фиксации в коммит при помощи команды [cci]$ git add *.php[/cci] .


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

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


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


Файл сброшен к исходному состоянию при помощи команды git checkout

Читайте также: