Вставьте ветки Git непосредственно в каталог сервера, чтобы файлы были видны вживую - PullRequest
10 голосов
/ 02 апреля 2011

Как я могу настроить удаленные каталоги в Git, где я могу локально передать ветку stage на удаленный компьютер и увидеть живые изменения на промежуточном сервере, например stage.example.com?

Понятие, которое я имею(часть того, почему я ухожу от SVN) заключается в том, что я могу поддерживать (локально) 3 разных «главных» ветки следующим образом:

  • master - используется для локальной разработки,рабочий каталог
  • stage - должен синхронизироваться с каталогом промежуточного сервера (удаленно)
  • live - это должен быть общедоступный веб-сайт (remote)

Идея, которую я имею (и, как утверждают другие, возможна), заключается в том, что я могу поддерживать эти удаленные "сайты" с моего локального компьютера без необходимости постоянного входа в оболочку удаленного сервера и запуска svn update (в моем текущем рабочем процессе SVN я должен делать это все время ...) или, конечно, в моем рабочем процессе Git запустить git pull на удаленном.

Как я могу настроить удаленные каталоги, чтобы я моглокально подтолкнуть мой stage Бранкh к staging remote server и посмотрите изменения (например) stage.example.com прямо сейчас?

Затем, когда stage все в порядке и проверено, я просто смогу на местена push на live пульт дистанционного управления для внесения изменений, которые я протестировал на stage на действующем веб-сайте.

Можно ли это даже сделать, или я получаю сумасшедшие идеи, которых просто нетпредполагается сделать с помощью Git?

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

remote server:      Dreamhost (shared account)
remote GIT version: 1.7.1.1
remote GIT client:  shell

local computer:     Mac Pro (Snow Leopard 10.6.6)
local GIT version:  1.7.2.3
local GIT client:   Tower.app // git-tower.com

Кроме того, пока у меня неудачно пробовал следующий рабочий процесс:

  1. Создание --bare Git репо на удаленном компьютере (чтобы я мог получить к нему доступ из любого места)
  2. Клонирование этого удаленного репо в локальный каталоги использовать приложение Git Tower для управления им
  3. Работать локально в master (HEAD)
  4. scp -r копировать репозиторий --bare git с удаленного сервера в мой удаленный рабочий домен stage.example.com
  5. Добавьте удаленный к локальной рабочей копии, а затем попробуйте нажать на origin/stage

Ясно, что это не работает, но я не знаю, почему и как это сделать лучше.

Исходя из опыта работы с SVN, я новичок в Git, но просмотрел множество уроков (Peepcode & ThinkVitamin) , но все еще не может понять, как это настроить.

1 Ответ

4 голосов
/ 02 апреля 2011

Единственное понятие, которое нужно реализовать с помощью DVCS («распределенной» VCS, такой как Git или Mercurial), - это то, что добавляет понятие публикации (push / pull) к понятию ветвления.
CVCS («централизованная» VCS, такая как SVN) имеет только разветвление (и одно центральное хранилище для отправки на сервер).

В вашем случае, подготовка или прямая трансляция - это шаги публикации, т. Е. Другое Git-репо, готовое для получения изменений, которые вы хотите видеть в промежуточной или реальной среде.

Это будет означать:

  • 2 ветви для отслеживания того, что принадлежит промежуточной (ветка "staging") или живой (ветка "live")
  • 1 удаленное репо без очков (, чтобы можно было нажать на него , выдвигая ветку staging или live
  • 1 ловушка после обновления для чистого репо для извлечения и обновления рабочего дерева (представляющего ваши фактические "промежуточные" или "живые" файлы)
  • 1 локальное репо, где вы добавляете голое репо в качестве удаленного, и где вы можете перейти к постановке или к жизни.
    Вы также можете клонировать голое хранилище на любой другой локальный компьютер, на котором вам нужно работать.

Разница между post-receive и post-update ловушкой заключается в том, что post-update выполняется один раз для каждой измененной ветви:
См. « Git hook для обновления различных веб-папок на основе ветки, отправленной на удаленный сервер » ТАК.

При первоначальном нажатии выполните «git push --all origin», и все удаленные репо будут созданы.

Идея о том, что на стороне сервера не должно быть никакого вытягивания: только git --work-tree=/path/to/your/live/files/ checkout live или git --work-tree=/path/to/your/staging/files/ checkout staging, в зависимости от параметров перехвата после обновления: вы извлекаете файлы только из репо в эти папки. 'на сервере.

Если вы делаете скрипт ruby ​​для своей ловушки, обязательно:

  • используйте правый Шебанг : #!/usr/bin/env ruby,
  • окружить вашу команду git backtick должно быть достаточно: `git ...`, как в этом сценарии ,
  • используйте ENV['HOME'] для указания homedir текущего пользователя в указанном скрипте, если вы хотите, чтобы работали такие команды, как `cd ~/stagedomain.com` или `--work-tree=~/stagedomain.com``~`, установленным на правильный путь),
  • если вы выбрали git pull, сбросьте GIT_DIR в той же строке, что и другие команды , как в другом вопросе : `cd ~/stage.mydomain.com && unset GIT_DIR && git pull core stage`.
...