Используйте Git в качестве живого зеркала - PullRequest
Новая
       39

Используйте Git в качестве живого зеркала

1 голос
/ 18 сентября 2010

У меня есть локальный компьютер (A), тестовый сервер (B) и сервер репозитория (C).
У меня следующий рабочий процесс:

  1. Код чего-то на A
  2. Зеркальное отображение изменяется на тестовой машине B
  3. . Если она работает хорошо, фиксируйте от B до C

. Сейчас я использую rsync для зеркалирования, но, поскольку хранилище увеличивается, это занимает некоторое времяsec) чтобы получить список файлов из B. Я хочу использовать Git вместо rsync, потому что это было бы намного быстрее, и у меня была бы локальная история вместе с хранилищем C.

Проблема в том, что я не нашел ни одногоспособ сделать в прямом эфире -зеркало с мерзавцем.Я могу сделать 

git add . && git commit -m "mirroring" && git push

на локальной машине, но как насчет сервера?

Является ли cronjob на каждые несколько секунд 

git checkout | awk '{print $2;}' | git checkout

правильным способом?

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

Ответы [ 3 ]

1 голос
/ 18 сентября 2010

Live-зеркалирование с помощью Git можно выполнить с помощью git hooks .

Вы можете настроить update ловушку, которая может выполнять действия rigt после обновления ветки . Установите этот хук на сервере B. Хук будет запускаться на сайте B каждый раз, когда вы вносите в него изменения. Внутри этого хука вы можете просто перенести изменения вперед на C (для чего вам нужно создать пульт). Крючок будет выглядеть так: 

#!/bin/bash
git push remote-of-c $3:$1
[ $? -ne 0 ] && { 
  echo 'Mirroring failed, check server settings and try again.'
  exit 1
}

Так что каждый раз, когда вы обновляете B, C также будет обновляться. Если что-то не получилось во время этого нажатия, вы увидите соответствующие сообщения в консоли, и ваш первоначальный запрос не будет успешным. Это то, что называется «зеркалированием», не так ли?

0 голосов
/ 18 сентября 2010

Я не думаю, что инструмент зеркалирования должен быть необходим, git кажется идеальным для этого.Как сказал fseto, я также рекомендую коммитить на A. Копирование ваших изменений в C должно быть сделано с помощью git push.Тогда, что вам нужно понять, так это то, что, поскольку у B есть рабочее дерево, переход к нему - определенно не лучший путь.Вы можете (по крайней мере, должны) отправлять только в голые репозитории (репозиторий без рабочего дерева: что вы должны иметь на своем сервере C).

Вместо этого на B вы можетеполучить изменения от A (B является git clone от A).Конечно, это можно настроить на cronjob.Это будет почти git pull, за исключением того, что вы хотите всегда отражать HEAD с сервера A, даже если вы переключаетесь между ветвями на A, удаляете коммиты, ветки и т. Д. Итак, на B я бы пошел наследующая команда: 

git fetch origin ; git checkout origin/HEAD

Эта команда предупредит вас, потому что она создаст состояние 'detached HEAD', но это нормально, так как вы не хотите фиксировать на B.

Теперь наконец, серверная часть:

  1. Вкл. C: Создайте серверное репо с помощью git init --bare
  2. Вкл. (или А?): добавьте свой сервер в качестве удаленного: git remote add server <repo-C>
  3. Вкл. B (или A?): Если все работает хорошо, отправьте изменения на сервер, например: git push server HEAD:master.Я пишу HEAD для общего характера, но вы можете вместо этого использовать ветку.

Надеюсь, что мои объяснения понятны ...:)

0 голосов
/ 18 сентября 2010

Используйте правильный инструмент для правильной работы. Я бы использовал unison или что-то подобное для зеркалирования.

Я бы также сделал коммит из A, а не из B. Так что вы можете пропустить зеркалирование каталога .git в вашей тестовой среде, это сделает его быстрее. Затем вы можете оставить более значимые сообщения о коммитах относительно того, что было изменено и почему ... вместо того, чтобы видеть бесконечный список «зеркальных» сообщений.

...