Как работает git удаленный репозиторий

хранилище («репозиторий») git — это то, что вы можете видеть в каталоге .git. вот содержимое этого каталога у вновь созданного хранилища:

$ tree .git
.git
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

в каталоге .git/objects хранятся объекты (типов commit, tree, blob), из которых можно извлечь содержимое тех файлов, которые и составляют ваш проект. файлы эти для хранилища — вещь сугубо опциональная. без них хранилище отлично функционирует (яркий пример вы можете наблюдать на сервере github.com). а вот вам для работы нужны именно эти файлы. они и называются потому «рабочей копией/деревом/каталогом« («working copy/tree/directory»).

когда вы «пушите» в удалённое хранилище, программа git передаёт объекты.

если из объектов хранилища, в которое вы передали новую порцию объектов, когда-то было развёрнута «рабочая копия», то, естественно, никакого обновления файлов в этой копии не произойдёт. файлы, составляющие «рабочую копию», будут рассинхронизованы с состоянием самого хранилища.

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

нормальной практикой является передача объектов в хранилище без «рабочей копии» (т.н. bare-хранилище), из которого впоследствии объекты (командой pull) забираются в хранилище с «рабочей копией». где из объектов уже и извлекается новое содержимое для файлов «рабочей копии».

судя по изложенному в вопросе, у вас нарушается эта нормальная практика. лучше так, конечно, не делать, но если от вас тут ничего не зависит, то привести содержимое файлов «рабочей копии» к тому состоянию, что содержится в объектах хранилища, можно, например, командой:

 $ git reset --hard

будьте внимательны и осмотрительны: эта команда затрёт все локальные изменения в файлах «рабочей копии».