Используйте Git локально для управления кодом из репозитория Surround SCM

Question

Я ищу двусторонний мост между Git и Seapine Surround SCM, похожий на git-tfs или git-svn. Когда я писал это, мне пришло в голову, что это действительно высокий заказ, поэтому я вполне ожидаю, что комментарии / ответы будут невозможны.

Я нашел этот вопрос, и я не думаю, что он действительно охватывает то, что я хочу. Я не хочу мигрировать из Surround, и мне все равно, знает ли Git что-нибудь об истории файлов в Surround.

Моя компания использует Surround SCM, который не отвечает моим потребностям. Я использовал git в Cygwin, чтобы перетасовать код, но Surround очень подходит для переключения веток Git под одним репозиторием SCM. Обычно SCM говорит мне, что я изменил некоторые файлы после переключения веток Git, но когда я запрашиваю diff, он говорит, что файлы идентичны. Это было удобное решение, но также очевидно, что это не очень быстрое решение, потому что Git и Surround на самом деле не общаются друг с другом и не очень быстрые друзья.

Я не уверен на 100%, что мосты, на которые я ссылался выше, являются идеальными аналогами для того, что мне нужно. Я включил мои требования и варианты использования ниже. Если есть какое-либо другое доступное решение, которое позволяет мне выполнять мои сценарии использования, я весь слух.

Мы собираемся перейти на TFS (в конце концов), поэтому я надеюсь на относительно простое решение, если оно существует. Я готов потратить некоторое время на изучение и настройку, но я действительно не знаю, с чего начать. У меня даже есть пропускная способность, чтобы написать собственное решение, если у кого-то есть советы, как к этому подойти.

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

Требования:

• Работает на Windows 7.
  • В идеале это означает, что его можно использовать в Git bash или Cygwin, но также приемлемы решения с графическим интерфейсом.
• Минимальная конфигурация / нет (то есть готовое решение или что-то, что мне нужно только для указания правильного каталога).
  • Предположим, у вас есть опыт работы с Git, Cygwin и Surround, и все три уже установлены.
  • У меня много возможностей для установки всего, что мне нужно, учитывая, что это компьютер компании.
• Желательно хорошо документировано.

Случаи применения:

• Используйте Git для управления параллельными исправлениями ошибок и реализации функций.
  • Если я внесу изменения в Git Master, я бы хотел, чтобы они были зарегистрированы в репозитории SCM.
  • Если я объединю ветку с Git Master, я бы хотел, чтобы SCM увидел эти изменения и поставил их для проверки.
  • Если я создаю ветку вне Master, я не хочу, чтобы она создавала соответствующую ветку в SCM: по крайней мере, не автоматически. Было бы хорошо, если бы это был вариант, но это определенно не требуется.

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

Answer 1

Это мое экспериментальное хакерское решение. Это вовсе не двусторонний мост, но он позволяет мне обрабатывать мои локальные рабочие пространства, используя Git, не нарушая Surround (пока).

Чтобы не расстраивать Surround:

• Инициализируйте репозиторий Git в рабочем каталоге Surround.
  • Surround (по крайней мере, так, как это было настроено IT в моей компании) игнорирует папку.git.
  • Добавьте.MySCMServerInfo к.gitignore. Убедитесь, что шаблон выглядит в подкаталогах: **/.MySCMServerInfo должен сделать свое дело.
• Клонируйте этот новый репозиторий Git в другое физическое место.
  • Surround не может заметить какие-либо изменения в этом клонированном репо, поэтому вы можете делать все, что захотите или без необходимости, без Surround.

Внесение изменений из локальных рабочих областей в центральное хранилище Surround является хакерской частью всего этого, и у меня пока нет проработанных перегибов.

• Убедитесь, что ваш рабочий каталог Surround содержит последние данные из репозитория.
• Используйте Git, чтобы объединить эти изменения с клонированным репо (т. Е. Репо, не отслеживаемое Surround).
• Разрешите любые конфликты слияния по мере необходимости.
• Зафиксируйте изменения в своем клонированном репо.
• Получить изменения в клонированном репо в оригинал.
• Проверьте изменения в Surround.

Это совсем не элегантно, но придает большую мощность Git моей локальной рабочей области, пока я жду TFS.