Синхронизация двух серверов Git между компаниями

1767
Matthias Reisner

Есть две компании. У каждого работает Git-сервер. Если компания A регистрирует некоторый код, он должен быть обновлен на сервере компании B и наоборот.

Два сервера должны быть синхронизированы друг с другом.

Серверная ОС: Ubuntu Server 14.04

GIT: Gitlab

Какое решение будет уместным в нашем случае (зеркальное отображение, хуки, ...)?

4
Вы думали об этом? Скажем, с обеих сторон внесены изменения в одну и ту же часть файла. Что происходит, когда оба активируются, и серверы пытаются синхронизировать друг друга? Кто решает, что такое разрешение конфликта? В худшем случае предыдущая модификация полностью теряется в этом процессе. Подобные вещи лучше решать, если один центральный сервер зеркально отображен на другой, а изменения кода вносятся только через один из них. Если это не сработает, у вас должен быть хотя бы один сопровождающий, который разберется с этим вручную. slhck 9 лет назад 0
Да, мы уже обсуждали эту проблему. Там будет четкое обязательство, кто будет нести ответственность за разрешение этого конфликта. С каждой стороны есть только один парень, который будет развивать и, возможно, продвигать изменения. Matthias Reisner 9 лет назад 0
Да, так что есть еще один человеческий уровень выше всего :) Какое программное обеспечение и ОС Git-сервера вы используете, в частности? Может быть, вы можете упомянуть об этом в вопросе и добавить несколько тегов. Это облегчило бы быть обнаруженным другими. slhck 9 лет назад 0
Обновил мой пост с дополнительной информацией. Но какую технику мы должны использовать для синхронизации (зеркальное отображение, хуки, ...)? Есть ли хорошие уроки для этого? Matthias Reisner 9 лет назад 0
Я не эксперт там. Я настроил и поддерживал GitLab некоторое время, но я должен был исследовать себя. Возможно, вы могли бы установить независимое от компании зеркало, которое получает push-сообщения от обоих серверов, откуда оба также непрерывно вытягивают. slhck 9 лет назад 0

1 ответ на вопрос

2
it3xl

ГИТ-синхронизация

  • Высочайшая производительность
  • Основан на современных версиях bash и awk (необходимо обновить в Mac OS)
  • Сложно для модификаций.
  • Удаление и создание веток в другом репозитории.
  • Более надежный для воссоздания синхронизации с любой позиции и с нуля.
  • Подготовлено для дополнительного уведомления автоматизации.
  • Для синхронизации используется один не пустой Git-репозиторий.

Чистый мерзавец с соглашением по мерзавцу

  • Гораздо больше настраиваемых
  • Медленнее
  • Если во время синхронизации вы совершите переход на другую сторону, этот запрос может быть отклонен (потребуется вторая попытка)
  • Минимальные технические зависимости
  • Вы не можете удалить ветви на другой стороне.
  • Хранилища Bare Git используются для синхронизации.

Общие заметки

  • Не зависит от реализации Git-сервера.
  • Имейте защиту от случайных удалений.
  • Проверено в производстве в течение длительного времени.
  • Синхронизация Git-тегов была удалена, потому что GitLab любит блокировать удаление тегов.
  • Отказоустойчивость и автоматическое восстановление синхронизации поддерживается. Особенно для проблем с сетью.
  • Разработанный, чтобы покрыть сотни случайных вещей, я не описываю здесь.

Как пользоваться

  • Выберите префикс для каждого хранилища. Только ветки с такими префиксами будут синхронизированы. См. Соглашение об именах ниже.
  • Опишите ваши оба репозитория в простом конфигурационном файле
  • Периодически запускается скрипт синхронизации
  • Решение применяется для каждого хранилища (против сервера). Может быть создано любое количество пар синхронизации.

Соглашение об именовании

Это любое префиксное имя. Каждая сторона имеет свой префикс, и конфликты без ускоренной пересылки для префиксных ссылок Git будут решаться в пользу владельца.
Примеры
company1/разрабатывают, company2-разрабатывают
company1/JIRA-123, company2-JIRA-321

Другие идеи

Подходы для синхронизации удаленных репозиториев Git

Ситуация

Скажем, у нас есть команды в отдельных компаниях. Каждая команда имеет свой собственный репозиторий, размещенный на отдельном git-сервере. Это часто случается для сценариев поставщик-клиент.