стратегия обновления сайта git - как синхронизировать dev и live репозитории? - PullRequest
0 голосов
/ 24 мая 2011

Вот как я строил свою стратегию обновления и резервного копирования на git-powered-site:

У меня есть SSH-доступ к Linux VPS, где размещен веб-сайт. Вот что я сделал:

1) НА СЕРВЕРЕ ВЕБ-САЙТА - Создано git-репо в соответствующей папке сайта (за один уровень до публичного корня):

cd /path/to/website
git init
git add -A
git commit -m "Website as of today."

2) НА РЕЗЕРВНОМ СЕРВЕРЕ - Создано зеркальное хранилище, для целей резервного копирования, на другом VPS:

git clone --mirror ssh://user@example.com/path/to/website website_backup

Обратите внимание, что зеркальное хранилище также является пустым хранилищем (без проверенного рабочего дерева).

3) НАСТРОЙКА CRONJOBS - одна на сервере веб-сайта, чтобы учесть изменения в файловой системе wesbite (изменения могут быть сделаны скриптами, FTP и т. Д.). Ежедневно запускается следующий скрипт bash:

#!/bin/bash
date=$(date +%d/%m/%Y)
cd /path/to/website
git add -A -v
git commit -m "Changes done at to website at ${date}"
exit 0

Таким образом, действующие изменения веб-сайта фиксируются в основной ветке хранилища.

На сервере резервного копирования установлен еще один cronjob. Он запускает следующий скрипт ежедневно, сразу после другого выше:

#!/bin/bash
cd /path/to/website_backup
git fetch -u ssh://user@example.com/path/to/website
exit 0

Таким образом, у меня на сервере резервного копирования ежедневно обновляется «резервная копия», которая также является git-репо, позволяя мне при необходимости перемещаться назад во времени. Мне не нужно бояться потерять материал из-за случайного перезаписи или удаления ... и процесс автоматизирован!

Ежедневно я получаю пару писем от cronjobs. Это позволяет мне проверить, что было изменено на веб-сайте, и подтвердить, что оба cronjobs работают правильно. (Другой cronjob настроен для выполнения резервного копирования базы данных.)

4) НАСТРОЙКА РАЗРАБОТКИ (ЛОКАЛЬНОЕ РЕПО + РАБОЧЕЕ ДЕРЕВО) - я извлек копию непосредственно с веб-сайта, а затем создал новую локальную ветку с именем «dev»:

git clone ssh://user@example.com/path/to/website website_local
git checkout -b dev

Теперь я могу поиграть с веткой разработки и выполнять свою работу.

С этого момента я бы хотел знать:

  • Как перенести мои изменения обратно на живой сайт?
  • Как вернуть изменения с сайта и объединить с моей веткой разработки?

Вкратце: как правильно синхронизировать живой сайт с веткой dev, не мешая?

Ответы [ 3 ]

3 голосов
/ 25 мая 2011

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

Чтобы обновить сайт, нужно просто перенести мою локальную ветку разработки в репозиторий сайта ...

git push origin dev

... и затем объедините изменения в живое дерево веб-сайта. Мне нужно SSH войти на сервер веб-сайта и выполнить следующую команду в папке веб-сайта:

git merge dev

Это перенесет внесенные изменения в ветке "dev" в ветку "master" (которая является текущей веткой сайта).

* УЛУЧШЕНИЕ ПРОЦЕССА ОБНОВЛЕНИЯ *

Для автоматического запуска слияния без необходимости входа в систему и запуска команды слияния из командной строки сервера я добавил хук post-receive в репозиторий живого веб-сайта. Сначала я создал файл ловушек, сделал его исполняемым, а затем отредактировал файл:

touch /path/to/website/.git/hooks/post-receive
chmod a+x /path/to/website/.git/hooks/post-receive
pico /path/to/website/.git/hooks/post-receive

Содержимое моего файла ловушек после получения:

#!/bin/sh
unset GIT_DIR
cd /path/to/website
echo "Merging dev changes to master branch."
git merge --ff-only dev
exit 0

Обратите внимание на параметр - ff-only , добавленный в команду объединения. Почему это там? Это происходит потому, что, будучи автоматизированным процессом, я не хочу, чтобы конфликты слияния сохранялись в файлах моего живого сайта. Поэтому, используя эту опцию, я заставляю объединение происходить только при наличии чистого контекста перемотки вперед. Если это чистое слияние не может произойти, я могу войти на сервер и вручную разрешить проблему или решить проблему, используя другой подход.

* ПРЕДОТВРАЩЕНИЕ КОНФЛИКТОВ И СИНХРОНИЗАЦИИ *

Во избежание конфликтов слияния на сервере, т. Е. Для обеспечения успешного слияния с ускоренной пересылкой, рекомендуется обновить локальное репо последними изменениями из удаленного репо. Другими словами: обновите локальную ветку разработки последними изменениями на веб-сайте (удаленная главная ветка), прежде чем отправлять наши изменения. Это можно сделать так:

git pull origin master

Еще лучше: давайте сначала обновим локальную ветку master, а затем объединяем ее с локальной веткой разработки (звучит как rebase):

git stash save
git checkout master
git pull origin master
git checkout dev
git stash pop
git merge master

Таким образом, наша локальная главная ветвь синхронизируется с удаленной живой ветвью главного веб-сайта, и объединение выполняется на 100% локально.

* НАЗАД К ПРОСТОТЕ *

Я создал псевдоним для облегчения вещей:

git config alias.deploy '!git stash save && git checkout master && git pull origin master && git checkout dev && git stash pop ; git merge master && git push origin dev'

Теперь я могу выполнить обновление сайта в реальном времени, используя псевдоним "deploy", например:

git deploy

Это будет:

  1. Переключиться на локальную главную ветку
  2. Обновление локальной ветки master с последними внесенными изменениями веб-сайта (синхронизация)
  3. Переключиться обратно на ветку dev
  4. Объединить изменения с локальной веткой разработчика (разрешение конфликтов здесь при необходимости)
  5. Нажмите локальную ветку dev на удаленной ветке dev сайта
  6. Если на сервере правильно настроен хук после получения, он автоматически перемотает репо на веб-сайт, поэтому изменения в dev будут опубликованы для производства!

У меня работает эта настройка, и она удовлетворяет мои текущие потребности, которые просты.

2 голосов
/ 24 мая 2011

Возможно, вы захотите обратиться к http://joemaller.com/990/a-web-focused-git-workflow/ и http://toroid.org/ams/git-website-howto для получения дополнительной информации об интеграции git и систем веб-развертывания.

Помните, git не является веб-развертываниемsystem (хотя с некоторыми простыми сценариями он может работать таким образом для людей с простыми потребностями).

0 голосов
/ 24 мая 2011

Или вы можете просто использовать Git и Jekyll как Github делает

...