Git submodules

I was asked to look into how to simplify the management of a large number of scripts within several application repo's, each repo had a scripts folder which was roughly the same but with just enough variability to historically justify the straight forward option of isolating the scripts. This however lead to some problems when script changes in common were needed.

The solution I worked on, was to create a shared scripts folder within a common 'devops' repo. Each script within this repo, such as build/prepare/publish, would work out via execution branching and parameters picked up via hosting profiles (nice way of saying parameter files) exactly what it needed to build for each application.

The common scripts folder in the devops repo would be accessed via a git submodule - this is effectively a checked out commit of the devops repo which is detached from the HEAD. In other words, it's a snap shot in time of the repo. This works nicely as it allows each application repo to pick when to update it's scripts folder rather than be forced to take potentially breaking changes.

The gitsubmodule can be created via this command,

git submodule add https://github.com/admgreen/myrepo

This would add the submodule at the root of your repo in a folder with whatever your repo is called, in the above example it would be 'myrepo'.

When you come to commit your changes to your application repo, you'll find two newly added files,

.gitmodules 
& 
$externalRepoName

The .gitmodules file will contain the path to your repo and it's url, the $externalRepoName file will contain the commitId that you've checked out.

This is a great way to manage common scripts/code which you don't think you'll update often but the practice of packaging whatever it is upto into say a nuget package is the wrong option.