Git deploy. Много разработчиков против одного сайта с админкой
Для таких целей можно и нужно использовать capistrano или что то похожее.
Я считаю, что наиболее удобный способ использовать post-receive хуки в центральном репозитарии гита (если таковой имеется), либо (если проект хостится на гитхабе) использовать post-receive url. При этом в деплой должны попадать изменения, залитые в одну конкретную ветку гита (для тестовой версии это чаще всего ветка develop). 

Опять же, если над сайтом работает несколько человек, проблем не возникает, так как каждый сначала сам делает merge своих изменений в develop, после чего push ветки develop в центральный репозитарий.

Файлы, которые меняются из админки, не должны быть в репозитарии (логично добавить их в .gitignore) Если же предполагается, что в репозитарии должны лежать изначальные версии этих файлов, а затем они могут правиться из админки (не очень хорошая практика), то логичнее будет вместо например файла translation.xml добавить в репозитарий файл translation.tpl.xml, и уже в самом скрипте деплоя (который вызывается из хука), копировать этот файл в настоящий translation.xml. Если же он был изменен из админки, то это уже ваша проблема, как обрабатывать такие конфликты. В нормально спроектированной системе такого быть не должно.

Вообще, очень удобно сочетать такую систему деплоя с использованием git flow. Тогда в ветку develop будет попадать только код, готовый к тестированию (и соответственно сразу выкладываться на тест), а в master будет мерджиться только production-ready код из ветки develop (если все сделать грамотно, то из master'а можно автоматом выкладывать на релиз, главное чтобы туда никто кроме руководителя проекта не пушил)

P.S. Если интересно, могу написать статью про использование git flow совместно с post-receive URL гитхаба для выкладывания тестовой версии.