Git Remote для тестирования
Я привык использовать Github в качестве резервного или центрального хранилища, а также проводить разработку и тестирование локально.
Теперь у меня есть удаленный тестовый компьютер, и я хочу иметь возможность отправлять локальные коммиты на удаленный, так что рабочий каталог удаленных компьютеров обновляется, что позволяет мне выполнять тестирование содержимого.
1) Большинство инструкций, которые я нашел для настройки удаленных устройств, заключается в использовании --bare init. Насколько я понимаю, это означает, что удаленному не хватает рабочего каталога, и он может принимать нажатия. Настройка пульта без --bare выдает ошибку, когда я пытаюсь нажать. Как я могу выполнить вышеуказанный рабочий процесс?
2) Является ли этот рабочий процесс даже хорошей идеей? Должен ли я иметь тестовое репо на удаленной машине в дополнение к голому репо. Я делаю толчок от разработки к голому репо, а затем, когда я готов к тестированию, я вытягиваю из голого репо в тестовое репо.
В случае, если это имеет значение, я спрашиваю относительно проекта Rails, но я не пометил этот вопрос как таковой, потому что я не понимаю, почему это так.
3 ответа
Я бы предложил использовать пустой репозиторий для push-уведомлений и второй репозиторий, который будет извлекать из него места, где будут выполняться тесты. Это будет легче понять, и вам не нужно быть осторожным, когда вы решите поцарапать тестовую среду и воссоздать ее. Если они находятся на одном сервере, в тестовом репо может быть установлен "альтернативный" для центрального сервера, поэтому объекты не будут храниться дважды (создаются с использованием git clone --shared).
Даже с этой настройкой вы можете легко запускать тесты автоматически. Просто установите хук post-receive или post-update в центральном репозитории, который запустит тест. Есть даже готовая реализация в contrib/continuous в источниках git, которые вы можете настроить под свои нужды.
Дело не в том, что вы не можете настроить push-репозиторий с рабочим каталогом. Git не позволит вам нажать на извлеченную ветку (потому что он не знает, как обновить его во время push и не будет знать, как это сделать позже), но это можно обойти, используя "detached HEAD". Однако это может привести к путанице, и вы рискуете случайно удалить важные данные, когда решите восстановить свою тестовую среду.
В большинстве случаев вы не хотите загружать репозиторий не в чистом виде. Причина в том, что нажатие обновляет только историю, но не рабочий каталог; это объясняется в git FAQ.
Так что да, ваше второе предложение будет путь. Вы даже можете использовать ловушку пост-обновления для автоматического обновления вашего тестового репозитория
То, как мы делаем это в наших проектах, - это создание отдельной ветки для каждого тестового сервера (staging, test, qa). Когда вы хотите внедрить некоторые изменения на одном из серверов, вы просто объединяете их в определенную ветвь для этого сервера, а затем используете Capistrano для развертывания.