Так получается, что для некоторых проектов самым оптимальным решением деплоя будет не использование каких-то специализированных средств деплоя вроде капистрано, а использование возможностей самого git. Например, когда нет разумной возможности вынести всю пользовательскую и иную статику/логи/прочее за пределы директории, обновляемой в момент очередного деплоя - так бывает, если проект - это какой-нибудь сайт на cms, у которой нет средств достаточных конфигурирования для этого, то есть время на переработку кода и связанные с этом затраты не окупится в конечном итоге.
В этом случае деплой может осуществляться например таким образом, на мой взгляд:
Есть локальный репозиторий(ии), в котором ведется разработка. В нем есть ветка test и ветка production, например. Также в нем добавлен удаленный bare-репозиторий где-то на сервере, в который выгружаются эти две ветки. С этим удаленным репозиторием могут работать например другие пользователи, или же оттуда можно самостоятельно забирать код, находясь на своей другой рабочей машине. У каждого разработчика, который подключен к этому удаленному репозиторию, есть свой тестовый локальный сервер.
И есть тестовый и рабочий сервера где-то в сети. Деплой из тестового репозитория на тестовый или рабочий сервер предполагается через подключение к нему репозиториев на этих серверах. И вот тут собственно и кроется мой вопрос.
Порядок действий подключения репозиториев на мой взгляд должен быть такой:
Инициализируется обычный репозиторий, в него клонируется тот удаленный bare-репозиторий, а точнее ветка test либо ветка production. Это удачно происходит, но вот беда - папки, куда должны попадать файлы этих репозиториев, могут отличаться.
То есть например у локального репозитория, на котором все ведут разработку, папка репозитория может называться site.com. Когда этот репозиторий копируется в bare, то там все равно, как будет называться эта папка - она там и не создается. Когда этот удаленный репозиторий копируется на других машинах или другими разработчиками, то это тоже не проблема - папка создается точно такая же, site.com, и локальной копии репозитория в принципе все равно, как она будет называться.
Но когда речь заходит про клоны репозитория на тестовом или рабочем сервере, то тот факт, что внутри клонированный репозиторий начинает выглядеть как:
.git
site.com
уже не устраивает, так как например DocumentRoot у этих серверов может выглядеть в случае тестового test.site-company.com, а в случае рабочего уже site.com или как угодно еще, например www.site.com.
В случае, если сервер, куда осуществляется деплой, был бы один, то проблемы в этом не было бы - просто у разработчиков на их локальных машинах папка репы называлась бы точно так же, как на рабочем/тестовом сервере. Но когда сервера два, то необходимо изменить рабочую директорию репозитория в одном из случаев минимум, а лучше - в обоих.
И вот тут у меня проблема - насколько я понимаю, это производится командой в корне репы тестового/рабочего сервера вроде
git --git-dir="blabla" --work-tree="blablabla"
Но как именно она работает, я честно говоря не понимаю и не могу найти внятных мануалов по этому. Может быть, кто-то сталкивался с этим и реализовывал таким образом либо подобным деплой средствами git на два разных сервера с различной структурой каталогов веб-серверов?
