Кто-либо действительно использует супер мерзавца / подпроекты?
Сначала установите пакет newtonsoft.json в Visual Studio, используя NuGet Package Manager, затем добавьте следующий код:
ClassName ObjectName = JsonConvert.DeserializeObject < ClassName > (jsonObject);
3 ответа
Используя подмодуль, вы определяете в своем рабочем пространстве Git (то есть в своем репозитории Git «суперпроекта») конфигурацию .
Под «конфигурацией» я имею в виду «список тегов или узла SHA-1, необходимых для работы в вашем рабочем пространстве».
(и под работой я имею в виду любые «усилия по разработке», которые вы делаете в своей рабочей области: классическая компиляция, или исправление, или слияние, или развертывание, или…).
Это тот случай, когда вы клонируете суперпроект и " git update " ваши подмодули: вы проверяете точные репозитории SHA1, которые ранее были зафиксированы в суперпроекте (записанном как gitlink в индекс ).
Другой режим - это когда вы работаете над вашим суперпроектом и над одним или несколькими субмодулями.
Это означает, что для данного подмодуля вы проверили конкретную ветку (вы больше не используете отдельный HEAD для содержимого этих подмодулей, а скорее указатель на конец ветки).
Затем «проталкивание подмодуля» означает обновление удаленного репозитория, содержащего этот подмодуль (и только этот).
Фактический трюк в этом последнем сценарии (который может заслужить ловушку, если вы хотите его) - это когда вы нажимаете суперпроект: вы должны быть уверены, что сначала разместили все свои подмодули.
Из учебного пособия по подмодулю :
Всегда публикуйте изменение подмодуля перед публикацией изменений в суперпроекте, который ссылается на это. Если вы забудете опубликовать изменение подмодуля, другие не смогут клонировать репозиторий (суперпроекта)
Не забывайте, что вы можете настроить подмодуль так, чтобы он следовал за веткой .
Если вы имеете в виду подмодули, то конечно.
Подмодули не знают и не должны знать везде, где они используются. Например, у меня есть один подмодуль, который используется в нескольких проектах, о которых я знаю (и, вполне возможно, в нескольких, которых я не знаю).
Направление в подмодуль никоим образом не влияет на версию кода, используемую проектом содержащий подмодуль, так что я не уверен, что вы хотите, чтобы хук делал.
FWIW, мы пытаемся перейти на git, и наш проект ( bitweaver , система управления контентом) представляет собой высокомодульную систему с почти 160 репозиториями ). «Сборка» обычно содержит два десятка или более суб-репозиториев. Мы использовали «виртуальные модули» в CVS, и это сработало для нас фантастически, однако у CVS есть свои ограничения для промежуточных коммитов.
Подмодули Git имеют некоторые серьезные ограничения, и вам определенно следует оценить реализацию Mercurial, поскольку она, безусловно, более удобна и гибка для внешних / модульных проектов (т.е. поддерживает другие системы VCS, даже HgGit).
Вот самые большие проблемы:
Каждый подмодуль жестко связан с конкретный коммит, когда вы «git submodule add» в суперпозитории. Это автор дизайн, и искал в качестве преимущества git, поэтому я не ожидал, что это изменится в ближайшее время. Это больно в система, подобная нашей, где коммиты всегда происходят в подмодули. Вы должны обновить супер проект, чтобы не отставать, или обновлять ваши дополнительные репо, которые нужно освоить после начальное обновление подмодуля. (видеть supergit ниже для нашего решения).
Вы не можете легко совершить и подтолкнуть к все суб-репо из корня. Это тоже очень раздражает, см. супергит ниже.
Различные подводные камни , которые могут быть мучительными, особенно вещи, которые «незаметно перезаписывают изменения».
supergit
Мы написали сценарий вызова сценария оболочки , который справляется с некоторыми проблемами. Он выполняет клонирование, инициализацию подмодуля, обновление и мастер проверки одним махом.Он также будет выполнять команды git для всех каталогов в супер-репо индивидуально (своего рода массовая обработка git).
HTH, удачи.