Рабочий процесс для использования подмодулей git в Visual Studio

У меня есть общий код, который я хочу разделить между несколькими решениями. Большинство примеров используют командную строку, но я хочу сделать это с помощью Visual Studio 2013 (и/или TortoiseGit)?

- SolutionShared
  - .git
  - Project1Shared
  - Project2Shared
- Solution1
  - .git
  - ProjectFoo
  - ProjectBar
  - [SolutionShared]
    - [Project1Shared]
    - [Project2Shared]
- Solution2
  - .git
  - ProjectBaz
  - ProjectQux
  - [SolutionShared]
    - [Project1Shared]
    - [Project2Shared]

Что я сделал, так это создать новое решение SolutionShared, добавить туда весь мой общий код и добавить его в свой собственный репозиторий git. Затем я использовал TortoiseGit (поскольку я не мог понять, как это сделать Visual Studio), чтобы добавить это разделяемое репо как подмодуль git к Solution1 и Solution2.

1. Что делать в Visual Studio?
Теперь у моих двух решений есть каталог SolutionShared. Я просто добавляю его два дочерних проекта (Project1Shared и Project2Shared) в Visual Studio?

2. Как внести изменения в общий код из не общих проектов
Если я участвую в одном из не-общих решений и внес изменения в что-то в подмодуле, как мне выполнить и вернуть его обратно в репозиторий общего разрешения (SolutionShared), чтобы он был доступен для всех решений, которые ссылаются на него

Ответ 1

После долгих экспериментов...

В VS добавьте совместно используемые проекты из подмодуля в решение. Похоже, что они живут вне "родительского" решения до версии.

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

Проблема в том, что VS не делает ничего из этого для вас, поэтому вам нужно использовать что-то вроде TortoiseGit или командной строки.

Ответ 2

Мы обнаружили, что самый простой способ сделать это - перенести каждую из наших разделяемых единиц кода в свой собственный проект Visual Studio и поместить каждый совлокальный проект Visual Studio в свое собственное репо.

Затем мы добавляем каждый из этих проектов в качестве подмодуля в любое Решение, которое им необходимо. Это полезно, так как многие из наших проектов могут быть очень большими по размеру и разделять многие из одних и тех же фрагментов кода. Мы также широко использовали пакеты nuget для этой цели, но, как правило, имели лучший успех и гораздо лучший опыт разработки/отладки с подмодулями.

В последние несколько лет в Microsoft значительно изменилось отношение к Git. Visual Studio Team Services (TFS Online) и On Prem-TFS (начиная с TFS2015) теперь хорошо понимают, как работают подмодули, и теперь могут создавать CI Builds, которые включают подмодули прямо из коробки.

Поддержка в on-prem TFS 2015 может быть немного ошибкой. TFS. Ссылки на субмодули имеют привычку становиться поврежденными, что приводит к сбоям в работе, которые перестают работать без предупреждения до тех пор, пока какой-либо подмодуль не будет виноват полностью и не будет добавлен - это не забавный процесс. По этой причине (среди нескольких других) мы теперь используем VSTS (TFS Online) для всех и не имели ни одного из тех же типов проблем. Я бы предположил, что это исправлено и во встроенном TFS 2017.

Как уже упоминалось, сама Visual Studio (IDE) все еще не понимает отношения между подмодулями. Он просто не может справиться с ними. Я попробовал несколько автономных инструментов Git, чтобы найти самый простой способ управления такой средой. Черепаха, кажется, обеспечивает самый простой и наиболее опытный опыт при нажатии, вытягивании и проверке на репозиции, содержащие подмодули. Я обычно использую команды для добавления подмодулей, но я подозреваю, что функция субмодуля Tortoise также прекрасно работает.

Когда вы передаете код репо с использованием Tortoise, он замечает, что подмодуль грязный и предложит вам зарегистрировать подмодуль перед проверкой родительского репо. Это действительно приятно. Однако вытягивание или выборка родительского репо может быть немного запутанным. Он фактически не обновляет подмодуль от удаленной ветки, он только обновляет его до любого уровня, который в настоящий момент проверен на основном репо-удалении, который не всегда является последним. В действительности, это желаемое поведение, это просто не сразу интуитивно, если вы этого не ожидаете.