Нет, это не так, как тянет работать.Может быть способ приблизиться к тому, что вы хотите сделать, но (1) как указано в комментариях, это может быть не путь [1], и (2) чтобы понять, что можно сделать, вам нужно понятьнемного больше о том, как git организует контент.
В качестве ответа на вопрос (и в случае, если вы решите следовать этому подходу):
Коммит в git - это снимок всегопроект.Вы объединяете коммиты, а не файлы, и pull - это, по сути, fetch, за которым следует слияние (по умолчанию).
Если вы хотите сделать что-то нестандартное с тем, как объединяется контент, тогдаЯ бы порекомендовал делать выборку и слияние отдельно.Например,
git checkout master
git fetch
git merge --no-commit origin/master
Затем удалите нежелательные изменения.Если файлы были просто зафиксированы неверно, может быть достаточно что-то вроде
git rm -r node_modules
.В более сложных случаях вы можете проверить версии файлов у вашего локального мастера.
Затем зафиксировать слияние. НО это создает нетипичное слияние, иногда называемое "злым слиянием".Это не естественный результат слияния его родителей, поэтому он может сбить с толку как пользователей, так и определенные команды git (например, rebase).Эту технику следует использовать с осторожностью.Вариант, который позволяет избежать этой проблемы, будет
git fetch
git checkout origin/master
git checkout -b temp
# undo the unwanted changes
git commit
git checkout master
git merge temp
git branch -d temp
. Это отделяет изменение, возвращаемое от слияния, при этом все еще достигая «правильного» конечного результата.
[1] Вероятно,более правильная вещь - переписать историю так, чтобы node_modules, кажется, никогда не было зафиксировано.Проблема заключается в том, что, поскольку эти коммиты явно выдвинуты, переписывание истории потребует некоторой координации с каждым разработчиком, который использует репо.
Очистку можно выполнить с помощью rebase, или filter-branch, или, может быть, даже просто commit --amend - в зависимости от того, сколько работы основано на плохом коммите.
Вы можетеобратитесь к документам git rebase в разделе «восстановление после исходной перебазировки» для понимания проблемы, которую вызовет перезапись, и работы, необходимой для ее исправления - понимая, что если разработчик делает «неправильную вещь» при ее исправлении, он можетотмените перезапись.
Затем вы сравниваете эту стоимость и работаете с тем фактом, что если вы не будете перезаписывать, этот каталог node_modules навсегда останется в истории, что приведет к переполнению репозитория информацией, которой вы не пользуетесь.не хочу носить с собой в репо.