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

Коротко — нельзя «клонировать» репозиторий прямо в уже занятую папку так, чтобы git начал отслеживать только часть файлов репо (например wp-content/*) без побочных эффектов, если в репозитории эти файлы лежат в поддиректории (wp-content). Есть несколько надёжных вариантов решения; я опишу два наиболее практичных и пронесу команды.

Вариант A — самый простой и безопасный (рекомендую)
- Клонируете репозиторий в отдельную папку вне веб‑корня:
  git clone <URL> ~/projects/my-wp-repo
- В локальном сайте удаляете/делаете резервную копию существующих theme/plugin, и создаёте символьные ссылки на файлы из клона:
  ln -s ~/projects/my-wp-repo/wp-content/themes/your-theme /var/www/site/wp-content/themes/your-theme
  ln -s ~/projects/my-wp-repo/wp-content/plugins/your-plugin /var/www/site/wp-content/plugins/your-plugin
Плюсы: нет конфликтов с другими файлами сайта, легко делать git pull/push в ~/projects/my-wp-repo. Минус: .git находится вне wp-content (но это обычно удобно).

Вариант B — «чистый» — сделать репо, в котором wp-content станет корнем (поддиректорию вынести в корень) и затем клонировать прямо в wp-content
Это удобно, если вы хотите, чтобы .git был непосредственно в /var/www/site/wp-content и git отслеживал только тему + плагин.

1) С помощью git-filter-repo (рекомендуется, быстрее и безопаснее):
- Установите git-filter-repo (если нет).
- Клонируете зеркало и отфильтруете:
  git clone --mirror <URL> /tmp/repo.git
  cd /tmp/repo.git
  git filter-repo --subdirectory-filter wp-content
Теперь репозиторий содержит историю только для содержимого wp-content, и эти файлы стали на корень репо.

2) Альтернатива (если нет filter-repo) — устаревший git filter-branch:
  git clone <URL> /tmp/repo
  cd /tmp/repo
  git filter-branch --prune-empty --subdirectory-filter wp-content -- --all

3) Клонируете/переносите в папку wp-content сайта:
  # либо клонируете уже изменённый локально репо в папку wp-content:
  git clone /tmp/repo /var/www/site/wp-content
  # либо переносите .git в /var/www/site/wp-content и делаете git reset --hard

Важные замечания к варианту B:
- filter-repo / filter-branch переписывают историю (создают новый репозиторий); если у вас чужой удалённый репозиторий и другие люди, то лучше создать новый удалённый репо для “wp-content-only” или договориться с командой.
- Перед операциями сделайте резервную копию.

Дополнительный вариант C — sparse-checkout + отдельный рабочий tree
Можно клонировать репо в отдельную папку, включить sparse-checkout и лишние пути не забирать, а в локальном сайте использовать симлинки или отдельный worktree. Но это сложнее и редко удобнее, чем A или B.

Резюме
- Если хотите простое и безопасное — клонируйте отдельно и используйте симлинки (вариант A).
- Если хотите .git прямо в wp-content и чтобы git отслеживал только плагины/темы — вынесите wp-content в корень репозитория с помощью git-filter-repo / filter-branch и затем клонируйте в /var/www/site/wp-content (вариант B).

Если скажете, какой путь предпочтительнее (хотите .git в wp-content или нет), дам точную пошаговую команду для вашей ситуации и как сделать бэкап перед операцией.

Коротко — обычным git clone это сделать нельзя. 
 Клонировать репозиторий поверх уже заполненного каталога Git не умеет и не должен . 
 
 Если задача — «подключить» Git к уже существующему каталогу и посмотреть, 
 чем он отличается от репозитория, не трогая рабочие файлы, 
 делается так: 
 
 
# Инициализируем репозиторий и подтягиваем данные с remote
git init
git remote add origin <url>
git fetch origin
# Создаём локальную ветку и переключаемся на неё
# (рабочий каталог при этом НЕ меняется)
git switch -c main
# связываем нашу локальную ветку с внешней
git branch --set-upstream-to=origin/main main
#  Перемещаем HEAD к origin/main без изменения рабочего каталога
git reset origin/main
 
 Результат: 
 - мы на ветке main , связанной с origin/main 
 - файлы на диске не перезаписывались 
 - git status и git diff показывают реальные отличия каталога от репозитория