Ссылки на проекты Git и Visual Studio
Хорошо, тогда короткая версия моего вопроса будет:
каков наилучший способ обработки ссылок на проекты в Git, когда у вас есть проекты, которые совместно используются в нескольких решениях, и как должны быть организованы мои репозитории Git?
длинная версия:
мы небольшая команда разработчиков (5 разработчиков), и в настоящее время мы используем TFS в качестве сервера управления версиями и сборки, а Visual Studio-наша IDE. Мне всегда нравилось пробовать что-то новое. пытаясь улучшить нашу среду разработки, я решил прочитать о Git, чтобы узнать, будет ли это хорошей заменой для части управления версиями TFS. Мы просто интегрировали Jira в наш рабочий процесс, поэтому я решил попробовать Stash как нашу среду Git из-за того, насколько хорошо она интегрируется с Jira. Теперь я пытаюсь выяснить, как организовать Git-репозитории, и именно поэтому я здесь. Теперь я опишу, сколько из наших решений организовано.
У нас есть куча решений. Некоторые из них являются библиотеками, а некоторые-программами, которые ссылаются на эти библиотеки через ссылку на проект в Visual studio.
Итак, главное, что меня смущает, - это как обращаться с библиотеками, на которые ссылаются во многих решениях?
должны ли мы начать управление версиями наших библиотек и поместить каждую библиотеку в отдельное РЕПО? Похоже, что этот путь потребует много дополнительного обслуживания, когда библиотека получает обновление, которое должно быть развернуто и что библиотека используется 20+ решения. Я ошибаюсь ? Еще один недостаток, который я вижу, заключается в том, что в Visual studio больше не будет ссылок на проекты, и это сделает отладку намного более утомительной.
должен ли я просто сделать большое РЕПО со всеми нашими решениями, и таким образом все наши ссылки обновлены?
Я также подумал, что, возможно, я мог бы сделать наш собственный репозиторий nuget, в котором есть все библиотеки тезисов, и таким образом не было бы так много хлопот для обновления ссылочных библиотек когда нужно. Это просто идея, и я не рассмотрел это должным образом, поэтому я не уверен, что это принесет какую-либо пользу.
Итак, есть ли люди, которые могли бы дать мне некоторые советы по этому поводу?
1 ответов
Это один из тех вопросов, на которые, к сожалению, нет единого ответа - это зависит.
самое простое решение-всегда иметь единое хранилище. Это позволяет избежать многих проблем управления несколькими репозиториями с разными версиями. Но это действительно работает, только если у вас есть одна версия всего; почти невозможно иметь разные циклы выпуска для двух продуктов в одном репозитории. Это путь безумия. По мере роста репозиториев до любого незначительный размер, он также не масштабируется.
как до точки, один параметр Git Submodules. Это позволит вам динамически загружать источник одного репозитория в другой при определенной фиксации или ветви. Конечно, это приходит с целым проблем, некоторые конкретные подмодули so и другие-это просто характер связывания репозиториев.*
некоторые люди действительно любят В Git Поддерево, который несколько изменяет и позволяет многократно извлекать, а затем импортировать историю папки через репозитории и обратно.
наконец, вы можете положиться на инструмент управления зависимостями, в зависимости от среды сборки. Я недостаточно знаю о Visual Studio, чтобы комментировать. В Atlassian мы (в настоящее время) используем Maven для решения этой проблемы. Если вы использовали JS, это может быть NPM/Bower, на Ruby это драгоценные камни. Может быть неприятно выпускать новую версию библиотеки X, чтобы сделать тривиальное изменение для программы Y, но по большей части это работает достаточно хорошо.
Это действительно постоянная проблема, и что-то, что я знаю, раздражает меня ежедневно. Я чувствую, что может быть возможность для лучшего решения, которое сочетает в себе лучшие подмодули и управление зависимостями, но я еще не нашел его.
надеюсь, это поможет?
* моя самая большая проблема с подмодулями, проблемы с инструментами в стороне, заключается в том, что она побуждает людей проверять абсолютные URL-адреса в других репозиториях. Этот работает отлично, пока вы не решите перенести свой git-сервер или один из репозиториев, и теперь все сломано. Я узнал на днях, что вы можете использовать относительные пути, что аккуратно, но не решает проблему.