Хотя ответ Мэтта может показаться достаточно простым (и на самом деле процесс может быть еще проще), он, скорее всего, приведет к проблемам.
Первая проблема ... да, эти шаги будут работать как написано (один раз), но они оставят вас в состоянии, в котором неясно, что вы должны делать дальше.
Вы упомянули принятие ваших локальных изменений, поэтому давайте предположим, что ваша отправная точка выглядит следующим образом:
... O <--(origin/master)
\
A <--(master)
То есть, вы клонировали репо из origin, а master был в коммите O (который может иметь любую произвольную историю; здесь это не имеет значения). Вы внесли некоторые изменения и зафиксировали их, создав коммит A; ваш локальный master теперь находится на A, что проверено.
Вы делаете git fetch, и оказывается, что были новые коммиты на origin/master. Теперь у вас есть
... O -- R <--(origin/master)
\
A <--(master)
Ваше местное отделение и рабочее дерево действительно не изменились, пока все хорошо. Теперь вы сказали, что хотите определить, какие файлы на вашем удаленном компьютере отсутствуют у вашего локального мастера. Вы можете сделать что-то вроде
git diff --name-only --diff-filter=A master origin/master
Это даст вам имена любых файлов, которые будут добавлены (--diff-filter=A) при переходе с master на origin/master. В дополнение к файлам, которые были созданы новыми коммитами, извлеченными с удаленного компьютера, здесь также будут показаны все файлы, которые вы удалили на локальном мастере. Если это проблема, вы могли бы сделать что-то вроде
git diff --name-only --diff-filter=A $(git merge-base master origin/master) origin/master
Это выяснит, где ваша локальная ветвь отклонилась от источника, и сравнит origin/master с ней вместо того, чтобы сравнивать ее с вашей веткой напрямую. С другой стороны, если вы и удаленный пользователь создали файл, он будет включен в список, если вы используете эту версию команды, но не если вы используете более раннюю версию.
Так что если вы создавая и / или удаляя файлы, вы должны подумать о том, какое сравнение имеет смысл (или посмотреть на оба, или на что-то еще); но если вы редактируете только существующие файлы, вы можете использовать любой из них.
Хорошо, все хорошо, давайте представим, что у вас есть список. И вы передаете этот список `1074 * checkout. Вы также можете автоматизировать это, если хотите,
git checkout origin/dev -- $(git diff --name-only --diff-filter=A master origin/master)
Теперь все новые файлы появляются в вашем рабочем каталоге (и в индексе) как незафиксированные новые файлы. Это может показаться бессмысленным - они были совершены на удаленном компьютере, верно? Но у вас все еще есть локальный коммит A, и в этом контексте файлы не переданы.
Вы можете их зафиксировать. Тогда картинка будет выглядеть примерно так:
... O -- R <--(origin/master)
\
A -- B <--(master)
, где появляется B для создания файлов, которые были добавлены с пульта. Другими словами, B содержит некоторые (но, вероятно, не все) изменения с пульта. (И хотя на приведенном выше рисунке показан только один новый коммит с удаленного компьютера, в реальном случае изменения могли произойти при любом количестве новых коммитов.)
Это нормально, но это может вызвать дополнительную работу, если вы когда-нибудь захотите рекомбинировать свою ветку с origin/master.
Теперь предположим, что вы вносите еще некоторые изменения и извлекаете снова с пульта:
... O -- R -- S -- T <--(origin/master)
\
A -- B -- C <--(master)
Что ж, вы можете снова сделать
diff --name-status --diff-filter=A master origin/master
На этот раз вы не можете использовать вариант merge-base. Если вы где-то отслеживали тот факт, что ранее вы вносили изменения до R, то вы можете сделать
diff --name-status --diff-filter=A origin/master~2 origin/master
(основываясь на том, что после R есть 2 новых коммита). Таким образом, эта процедура повторяется, но она становится немного более сложной, чем вы go. Я предполагаю, что всегда перемещая тег к последнему коммиту, из которого вы скопировали файлы, вы можете сделать это немного проще.
Но вы все больше и больше расходитесь с тем, что происходит на удаленном компьютере. , То, что может не имеет значения .. или может.
Например, если репо содержит исходный код для одного программного проекта, то копируемые вами изменения могут зависеть от изменений, которые вы игнорируете (риск, который увеличивается со временем / числом внесенных изменений). Конечно, в зависимости от характера вашего репо, возможно не относится к вам, хотя это будет нетипично.
Итак, суть - может быть, все, что вам подходит, и эта версия процедуры может делать то, что вы хотите. Но на самом деле я не рекомендую взаимодействовать с пультом в чем-то похожем на типичный проект.