Git и ссылки на проект Visual Studio - программирование

Хорошо, тогда короткая версия моего вопроса:

Каков наилучший способ обработки ссылок на проект в Git, когда у вас есть проекты, которые совместно используются несколькими решениями и как должны быть организованы репозиции Git?

Длинная версия:

Мы небольшая команда разработчиков (5 разработчиков), и в настоящее время мы используем TFS в качестве нашего сервера управления версиями и сборки, а Visual Studio - это наша IDE. Я всегда старался пробовать новые вещи и пытаться улучшить среду разработки, поэтому решил прочитать на Git, чтобы узнать, будет ли это хорошей заменой для части управления версиями TFS. Мы просто интегрировали Jira в наш рабочий процесс, поэтому я решил попробовать Stash в качестве среды Git из-за того, насколько хорошо он интегрируется с Jira. Сейчас я пытаюсь выяснить, как организовать репозиции Git, и именно поэтому я здесь. Теперь я расскажу, как много наших решений организовано.

У нас есть множество решений. Некоторые из них - библиотеки, а некоторые - это программы, которые ссылаются на эти библиотеки через ссылку Project в Visual studio.

Итак, главное, что меня смущает, это то, как обращаться с библиотеками, на которые ссылаются многие решения?

Должны ли мы запускать версии наших библиотек и размещать каждую библиотеку в отдельном репо? Похоже, что этот способ потребует много дополнительного обслуживания, когда библиотека получает обновление, которое должно быть развернуто, и эта библиотека используется 20 + решениями. Я ошибаюсь? Еще один недостаток, который я вижу, заключается в том, что в Visual Studio больше не будет ссылок на Project, и это сделает отладку намного более утомительной.

Должен ли я просто делать на большом репо все наши решения, и таким образом все наши ссылки обновляются?

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

Итак, есть ли там люди, которые могли бы дать мне некоторые советы относительно этого?

Ответ 1

Это один из тех вопросов, который, к сожалению, не имеет ни одного ответа - это зависит.

Самое простое решение - всегда иметь один репозиторий. Это позволяет избежать многих проблем управления несколькими репозиториями с разными версиями. Но это действительно действительно работает, если у вас есть одна версия всего; почти невозможно иметь разные циклы выпуска для двух продуктов в одном хранилище. Таким образом, безумие. Поскольку репозитории растут до любого незначительного размера, он также не масштабируется.

Как указано выше, один из вариантов - Git Подмодули. Это позволит вам динамически загружать источник одного репозитория в другой в конкретном коммите или ветке. Конечно, это связано с целым множеством проблем, некоторые специфические, поэтому подмодули и другие - это просто связывание репозиториев. *

Некоторым людям действительно нравится Git Subtree, который несколько изменяет и позволяет вам повторно извлекать и затем импортировать историю папки через репозитории и обратно.

Наконец, вы можете положиться на инструмент управления зависимостями, в зависимости от вашей среды сборки. Я не знаю достаточно о Visual Studio для комментариев. В Atlassian мы (в настоящее время) используем Maven для решения этой проблемы. Если вы используете JS, это может быть NPM/Bower, на Ruby it Gems. Это может быть разочаровывающим, чтобы выпустить новую версию библиотеки X только для того, чтобы внести тривиальное изменение в программу Y, но по большей части она работает достаточно хорошо.

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

Надеюсь, что это поможет?

* Моя собственная самая большая проблема с подмодулями, проблемы с инструментами в стороне, заключается в том, что она побуждает людей проверять абсолютные URL-адреса на другие репозитории. Это работает отлично, пока вы не решите перенести сервер Git или один из хранилищ, и теперь все сломано. На днях я узнал, что вы можете использовать относительные пути, который является опрятным, но не решает проблему.