Инициализация частных репозиториев на рабочем сервере - PullRequest
1 голос
/ 24 февраля 2012

Теперь я хочу инициализировать частный репозиторий на моем рабочем сервере в папке www приложения (например, /var/www/app.com/web/), а затем клонировать его в качестве промежуточного репозитория для моего тестирования. сайт (например: /var/www/test.com/web/app.com/) и, наконец, клонировать из промежуточного на локальный для работы с кодом.

Я планирую это правильно?

Я следую этим урокам, чтобы узнать больше о настройке «git server» и инициализировать частные репозитории:

Последний вопрос, этот урок об успешной модели ветвления Git, где будет применяться? На основной частный репозиторий (рабочий сервер) локальный или смешанный? Я еще не прочитал это полностью, я сделаю это как можно скорее.

EDIT:

  • Если это имеет значение, я пытаюсь сделать это на сервере, на котором выполняется конфигурация ISPConfig.
  • Это не обязательно работать / быть, как упомянуто выше, если есть "более здоровый" способ ... рад узнать об этом.

Эта http://www.howtoforge.com/the-perfect-subversion-server-debian-lenny-ispconfig-3 и эта http://www.howtoforge.com/installing-subversion-and-configuring-access-through-different-protocols-on-ubuntu-11.10 версия GIT - вот что я имел в виду

Ответы [ 2 ]

5 голосов
/ 22 марта 2012

Правильно ли я планирую?

Каскадные репозитории звучат довольно сложно и не нормально.

Рассмотрим любой заказ клиент / спутник / ребенокиз чистого git репо, который вы делаете.Ваши промежуточные и производственные установки должны быть доступны только для чтения и проверять определенные ветви, вы, возможно, уже знакомы (потому что почти все git-вопросы получают ссылку на него - этот вопрос теперь не исключение) с git-flow , которыйможет дать некоторое представление о том, как правильно настроить свои филиалы и, следовательно, оформить заказы.

Настройка сервера Git

Это руководство , вероятно, является единственным, которое вынужно следовать.

Обратите внимание, что если вы настроили пользователя git с домом на /home/git и создали репо на /home/git/project.git, это означает, что вам не нужны абсолютные пути.Т.е.

(server) $ cd /home/git
(server) $ mkdir project.git
(server) $ cd project.git
(server) $ git --bare init

Тогда, где вы хотите:

(home) $ git clone git@server:project.git

Конечно, вы также можете разместить свои репозитории git где угодно и просто изменить домашний каталог пользователя git (в * 1027).*) для достижения того же.

Обновление при нажатии

Если вы хотите обновлять извлечение при каждом отправлении в хранилище, вам нужен хук после получения, чтобысделай это.Сначала настройте себя правильно:

(server) $ cd /var/www/app.com/web/
(server) $ git clone -b production-branch /home/git/project.git . # it's local - use a file path
(server) $ cd /var/www/test.com/web/app.com/
(server) $ git clone -b staging-branch /home/git/project.git .

Затем создайте /home/git/project.git/hooks/post-update с

cd /var/www/test.com/web/app.com
git --git-dir /var/www/test.com/web/app.com/.git pull #> /dev/null 2>&1 & #uncomment after testing

Убедитесь, что:

  • Файл ловушек является исполняемым и принадлежит git
  • Git (также) находится в той же группе, что и владелец извлеченных файлов, в противном случае вы получите ошибки разрешения при нажатии

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

Возможно, не стоит обновлять ваш действующий сайт автоматически,Вместо этого

(home) $ git checkout production-branch
(home) $ git merge staging-branch
(home) $ git push # updating production-branch
(home) $ git checkout feature/i-was-working-on-this
(home) $ ssh server 'cd /var/www/app.com/web/; git pull'
# Manual Post update checks

Если вы сделали это автоматически и, например, обновление оставило ваш производственный сайт в непригодном для использования состоянии - вы можете об этом не знать (до тех пор, пока не получите предупреждение pingdom со словами "Производство сайта в автономном режиме »).Было бы безопасно автоматизировать обновление вашего живого сайта, если вы получили значительное тестовое покрытие и автоматизированный процесс развертывания - но пройдитесь перед запуском:).

Direct push

Вы можете, если вы действительно хотите перейти к проверке, если вы установили

[receive]
    denyCurrentBranch = ignore

В файле .git / config проекта, если нет локальных изменений, которые также должны обновить рабочую копию (IIRC).

2 голосов
/ 24 февраля 2012

Это хорошая идея, но требует немного больше работы.

Git не будет обновлять рабочую копию, когда вы отправляете в репозиторий без обнажения, если вы не поможете ему, определив post-update ловушку для выполнения git reset --hard, когда извлеченная ветвь помещается в, плюс отключение проверки по умолчанию от нажатия на извлеченную ветку (точную опцию я не помню, посмотрите на git-config справочную страницу).

Обратите внимание, что выполнение git reset --hard отменит любую локальную модификацию. Написание хука для сохранения локальной модификации немного сложнее, но также может быть выполнено. Однако у вас не должно быть локальной модификации на рабочем сервере, верно?

При наличии подходящей зацепки это довольно разумный рабочий процесс для небольших установок, когда у вас мало серверов.

Для более крупной установки у меня будет пустое хранилище на отдельном сервере, и ловушка приведет к запуску git pull в производственном репо с использованием ssh trigger. Преимущество заключается в том, что у вас будет центральное хранилище на сервере, недоступное извне, и, следовательно, вы сможете лучше его обезопасить.

...