Рекомендуемый рабочий процесс для публичных и частных форков публичного репозитория, созданного в GIT-SVN - PullRequest
Новая
       32

Рекомендуемый рабочий процесс для публичных и частных форков публичного репозитория, созданного в GIT-SVN

4 голосов
/ 04 октября 2010

Я пытаюсь настроить три вещи:

  1. публичное зеркало GIT публичного репозитория SVN
  2. публичный форк этого репо, где несколько участников могут устанавливать патчи
  3. частный форк публичного репо от # 2

Я знаю, как сделать # 1, но ищу советы по # 2 и # 3: как настроить, как сохранить синхронизацию, что следует избегать и т. Д.

Вот более подробная информация:

Я работаю с основанным на SVN веб-приложением с открытым исходным кодом, механизм отправки исправлений которого является медленным и неэффективным: исправления прикрепляются к ошибкам, отправляемым в системе отслеживания ошибок, а спустя несколько недель или месяцев эти исправления превращаются в багажник.

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

Я бы хотел найти решение обеих этих проблем на основе GitHub. Я хотел бы закончить с тремя вещами:

  • "mirror" - Зеркало SVN GitHub, автоматически синхронизируемое с последними изменениями SVN через автоматизированный процесс (как в этой статье ), который я или другой участник, внесший исправление побежит. Это облегчит мне или кому-либо еще создание публичной или приватной ветки проекта без возни с SVN.
  • "contrib" - для себя и нескольких отправителей патчей, которым я доверяю, я бы хотел установить публичный ветвь (или ветвь?) "Mirror", где мы могли бы фиксировать патчи, которые мы бы сделали хотел бы увидеть в конечном итоге показать в SVN. Это также может упростить и сделать более эффективными для основных коммиттеров извлечение исправлений обратно в SVN.
  • "ourfork" - наконец, наша компания хочет не устанавливать частный ветвь "contrib", где несколько разработчиков могут добавлять частные функции, которые применимы только к реализации нашей компании

Некоторые конкретные вопросы:

  • имеет ли этот подход смысл? Есть ли более простое решение, которое мы должны использовать вместо этого?
  • как обеспечить синхронизацию «contrib» с «зеркалом»? Существует ли магия GitHub для автоматического применения новых коммитов, если они не конфликтуют? Предполагая, что нет, каков хороший рабочий процесс, чтобы обеспечить синхронизацию contrib с его родителем?
  • "ourfork" логически будет внуком "mirror". Каков правильный рабочий процесс, чтобы поддерживать его в актуальном состоянии с изменениями из «mirror» и «contrib»? Должен ли я установить «contrib» как мой единственный пульт? Или настроить оба в качестве удаленных - и если да, то каков правильный процесс для слияния?

Я зачитал @ 10q ответ на аналогичный вопрос, и я подозреваю, что он отвечает на большинство вопросов выше, но я новичок в Git и не уверен, применим ли его ответ к моему делу.

Ответы [ 2 ]

2 голосов
/ 12 мая 2012

Я бы порекомендовал вам взглянуть на SubGit . Это инструмент для создания и синхронизации Git-репозитория, связанного с SVN-репозиторием. Он имеет преимущества перед другими решениями, такими как:

  • одновременно безопасные коммиты (так что если один из авторов вносит коммит в Git и еще один в SVN в течение той же миллисекунды, ничего плохого произойдет: если их изменения вступят в конфликт, один из них просто получит «Устаревшая» ошибка)
  • лучший перевод SVN↔Git понятий, таких как игнорирование, EOL, произвольный ветки (не только главные) и теги и т. д.

Но есть ограничение: у вас должен быть доступ к серверу SVN, поэтому, возможно, ваше решение на основе GitHub не будет работать. Но вы можете взглянуть на замены GitHub, такие как GitLab, Luna-tool и другие ( Git Server Like GitHub? ).

1 голос
/ 10 октября 2010

Я не могу дать полный ответ, так как ваши настройки довольно требовательны.

Возможно, я бы попытался получить одного из коммитеров SVN на борту.Затем я бы назначил его ответственным за перебазирование ветвей функций поверх клона git-svn, а затем повторное внесение изменений в Subversion.Недавно я сделал очень простой пример этого рабочего процесса в скринкасте .

Для этого требуется очень тесная петля обратной связи с одним из коммиттеров SVN, и для того, чтобы сохранить историю линейнойвам придется много перебазировать, что опять же затрудняет синхронизацию распределенных репозиториев.Я не уверен, что это сработает для вас.

...