factorloha.blogg.se - Git add remote submodule

#Git add remote submodule update#
#Git add remote submodule code#

$ git init mainĪfter whole code-base has been moved in, we can push it out to GitHub. We create repository for localization provider core/common module.

netcore (.NET Core repository, has dependency on main).

epi (repository for EPiServer integration, has dependency on main and aspnet).

aspnet (repository for Asp.Net Mvc applications, has dependency on main module).

main package repository (core/common functionality).

You start with top-level module repo which does not have any external dependencies on any other module (core/common functionality). Now when you have decided module boundaries it's time to create repositories for each of the module. Create Repositories with Submodules Create Main Module Repo This gives nicer debugger experience for developer without any hustle to enable symbols and be able to "step into" the package source code. Decision has to be made around type locations - where each type should go and which project will be used where.Īctually for development purposes using ordinary project reference is much more preferred way to work with. It's important to understand where each module ends and where next begins as you be referencing each other through sort of NuGet package references. This is a blog post about the stuff I had to do. So decided to split whole code-base into git submodules and setup separate repositories for each of the sub-systems.

abstract/core packages containing only general purpose functionality (like expression tree walker or resource definition attributes)Īs you can see there might be some issue with having multiple purpose packages (with different life-cycles and versions) located in single Git repository.

Later realized that there is actually not so much to do to add support for Asp.Net Mvc (.NET Framework) applications and later also for. Initially there was just a EPiServer package to add support for database driven localization resources.

#Git add remote submodule update#

So first of all you need to update your fork to get all upstream changes.During development of DbLocalizationProvider I had single repository in GitHub containing more that one package as result of the build. Not any future commits which you might not know of. The revision the submodule repo had when you added it. This is necessary because you always want to have a specific revision when cloning your main repo. This cannot be done by a simple “git pull” because git submodules are only pointers to a specific commit revision in another repo and therefore have a detached HEAD.

#Git add remote submodule code#

If the maintainer updates his code you can then merge/update everything you want into your fork and keep your patches that didnt make it upstream.įrom time to time you then need to update the submodule in your projects because the upstream maintainer has added a feature or version you want to have. The benefits are that you can modify the fork to your needs and even open pull requests to the maintainer. Git submodules are a great way of adding 3rd-party libraries/modules to your project.īasically you are forking the 3rd-party repo and add your own fork as submodule to your projects.