In almost all companies where I worked, we had some sort of blueprint that a project in source control should adhere to. For example, when creating a Visual Studio 2010 project, I have to

• create .gitignore to exclude Visual Studio files and folders (e.g. bin, obj)
• create folders (src, lib)
• create files (e.g. build.proj for build automation)

And so much more. For other types of projects, be it C/C++, Java, Rails or Objective-C, the steps will be different. However, organisations typically "standardise" the project layout for each type of project.

One way this could work is to designate a repository (let's call it "Visual Studio Solution") as a blueprint. Since its just a git repository, I can commit the standard folder structure I desire. I can also define basic permissions. Then when I create a Stash repository, I can specify "Visual Studio Solution" as the blueprint for my new repository. The expectation would be for Stash to create a repository that is almost identical to "Visual Studio Solution".

More often than not however, I may want to customise what should happen. If my "Visual Studio Solution" has a file in the "src" folder called "MySolution.sln", I'd like to be able to rename it appropriately. This may require that I commit a manifest file to my blueprint project. The manifest may describe variables that should be entered, files that should be renamed and so forth. So when I create a subsequent project, Stash will ask me to enter some variables, which can be used to rename files. In addition, I may want to replace text within files (such as build.proj with the solution).

The idea is to promote a consistent structure within the repository. It may shave an hour off the time it takes to create a repository that conforms to organisation standards.

In essence, something similar to a Confluence blueprint.