Быстрое развертывание небольших web-приложений на сервере посредством git push

[ataraev]

Почему бы не посмотреть в строну нармального деплоя, обычно в добавок к коду еще может измениться и БД, а так же потребоваться перезапуск сервера приложений
P.S.
я использую capistranorb.com/

[Smartfon]

Есть еще такой способ: Git и публикация сайта

[foxel]

Спасибо, схема довольно удобная.

[Pilat]

Первым же решением, пришедшим в голову, оказывается совсем не git, а rsync. Технология примерно такая: на девелоперской машине собираем копию (более-менее точную) того, что получится на сервере, и rsync'ом обновляем сервер (ну или лучше обновить на сервере копию, а с этой копии уже обновить сам сервер — чтобы уменьшить время простоя). После этого запускаем скрипты, настраивающие что-то на сервере — права доступа, директории, базу… что угодно, и перезапускаем серверную часть — что может потребовать рутовых прав.

Почему не git: причин может быть много, например отсутствие git на сервере, наличие больших бинарных кусков (которые с git'ом не дружат), нежелание выкладывать на сервер что-то кроме текущей версии, наличие в git файлов не для выкладывания на сервер, сложность отладки хуков по сравнению с обычными скриптами.

[foxel]

rsync, не спорю, достаточно гибок, но не всегда удобен: в случае когда рядом с кодом появляется контент, производимый сайтом, нужно либо действительно держать на девелоперской машине практически полную копию продакшна (не только код), либо настраивать rsync не совсем тривиальным путем.
Насчет бинарных кусков не совсем понял — зачем их переливать? Вряд ли код имеет большие бинарные блоки. Бинарные файлы это картинки в основном.
Отсутствие гита конечно ограничивает применение рецепта, но если гит уже есть — решение довольно просто внедряется.

[antarx]

Мне кажется, вы усложняете. Если вы работаете над проектом один, не имеет смысла разводить много репозиториев: можно прямо в локальном репозитории добавить post-commit хук, выливающий rsync'ом изменения и перезапускающий что надо. Если работает несколько человек, в любом случае желательно иметь центральный репозиторий (лучше — bare, с обвязкой типа gitolite), и оттуда по post-update хуку выливать изменения.

Такая схема, в частности, даст возможность иметь несколько версий запущенного проекта (production, testing...)

Если что, такой командой можно получить ветку в не-bare репозитории.
BRANCH=`git rev-parse --abbrev-ref HEAD`
Такой — в bare:
BRANCH=`git rev-parse --symbolic --abbrev-ref $1`
И такой командой можно вынуть данные из репозитория:
git archive --format=tar HEAD | (cd ${DIR} && tar -xf)

[NoN]

А если не смержится? Если --ff-only не сработает.

Можно делать настроить 'receive.denyCurrentBranch' configuration variable to 'refuse' пушить в текущую ветку. Тогда в хуке нужно сделать только git checkout -f.

Но ещё правильнее пушить не бранчи, а теги — вы же не будете на сервере ничего коммитить, значит и бранч вам не нужен. Создаём тег, пушим его на сервер. А на сервере хук git checkout -f tagname. После этого все бранчи на сервере даже можно удалить.

[foxel]

Если не смержится значит что-то меняли/коммитили на проде, что не есть гут. --ff-only какраз для того чтобы в случае отклонения от основного принципа работы с проектом все сломалось. На всякий случай, так сказать.

насчет тега спасибо — попробую.

[NoN]

Ну это зависит от процесса разработки и выкладки. У нас иногда переключались ветки и это было вполне валидно.

Вначале работает какая-то одна ветка с релизом, в неё добавляются бакфиксы-бэкпорты из мастера. Потом новый релиз — новая ветка от свежего мастера. И продакшн должен просто перепрыгнуть без мержа.