Что делать, если подмодуль Git перемещается на другой сервер? - PullRequest
4 голосов
/ 11 ноября 2011

Я организую исходный код нашего продукта в кучу разных репозиториев Git. (И я новичок в Git). Некоторые из них будут использовать другие репозитории на том же сервере через субмодули.

Насколько я понимаю, подмодуль в Git является указателем на определенный коммит в другом репозитории и определяется следующим образом:

  • URL-адрес удаленного подмодуля (например, git: //foo.com/git/lib.git)
  • Подкаталог для клонирования репозитория подмодуля в (например, include / foo)
  • Идентификатор коммита, на который мы ссылаемся

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

Например, предположим, что я храню репозитории Super и Sub в git: // PrivateCompanyServer / repositories / *. Super ссылается на Sub через файл gitmodules: git: //PrivateCompanyServer/repositories/Sub.git. Несколько разработчиков делают сотни коммитов в Super - почти каждый коммит в Super имеет снимок gitmodules с этим URL в нем. Несколько выпусков продуктов помечены тегами, и все виды ветвей имеют URL в gitmodules. Теперь предположим, что PrivateCompanyServer аварийно завершает работу, и мы переносим код на другой сервер. Или мы реорганизуем структуру каталогов на PrivateCompanyServer. Или что угодно. Теперь у нас есть сотни коммитов в Super со ссылкой на репозиторий Sub по старому URL, который больше не существует. Очевидно, что файл gitmodules можно исправить в начале ветки разработки, и мы можем двигаться дальше. Но будут все виды старых коммитов, к которым нам, возможно, придется вернуться по причинам обслуживания, и все они будут ссылаться на старый URL, который больше не будет работать. Как справиться с этим?

Очевидно, что это можно решить путем перебазирования / «переписывания истории», чтобы все файлы gitmodules в репозитории имели новый URL, но я думаю, что это не вариант, потому что почти каждый коммит в Super получал бы новый идентификатор коммита. Все, что ссылается на Super, включая проекты «Super-Super», использующие Super в качестве подмодуля и локальные репозитории разработчиков, все сломается - правильно?

Так, каков лучший способ справиться с этим? Если вы храните коллекцию репозиториев на сервере частной компании - некоторые из которых ссылаются на другие репозитории через субмодули - что вы делаете, когда сервер меняет имена, - следовательно, аннулируете старые URL-адреса в файлах gitmodules?

Единственный обходной путь, о котором я могу подумать, - это создавать "множество веток" из каждого коммита назад в истории, просто чтобы содержать исправленные git-модули. Похоже, что это сделает много беспорядка и будет громоздким. Похоже, должен быть лучший путь - наверняка я что-то упустил?

1 Ответ

2 голосов
/ 11 ноября 2011

Пока вы не запустите git submodule sync, значение в .gitmodules не будет влиять на путь подмодуля в данной проверке после первой инициализации подмодуля (после этого путь для подмодуля хранится в файле .git/config).

Таким образом, вы можете просто изменить путь в извлечении один раз (используя git submodule sync в коммите с обновленным путем), и он сохранится без проблем.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...