Robware Software by Rob

Git: Ignoring specific lines - prevent personal config being comitted in 3 easy steps!

One of the key things I like to do when setting up a new project for my team is to make it as easy as possible to get up and running. One major facet of this is making sure any local dev config stays local, even if it's part of a deployed config file (as is the case in Umbraco). In this situation you need to be able to ignore or exclude certain lines within git.

Note: I'll be using what I did with Umbraco throughout as a practical example, but the same principles apply to any file.

The three steps

First I created a new bash script, clean-umbraco-config.sh, to clean out the offending content:

#!/bin/sh

sed \
-e 's/<add key="Umbraco.Core.ConfigurationStatus" value=".*" \/>/<add key="Umbraco.Core.ConfigurationStatus" value="" \/>/g' \
-e 's/<add name="umbracoDbDSN" connectionString=".*" providerName=".*" \/>/<add name="umbracoDbDSN" connectionString="" providerName="" \/>/g' \
$1

What this file is doing is using the Linux tool sed to replace the installation specific config with a blank entry. This will allow a fresh clone to go through the first run without a new developer to the project having to do this manually.

The second step is to setup the git clean filter in the repository's .gitconfig file:

[filter "umbraco-config"]
	clean = ./clean-umbraco-config.sh

This saves the new dev from having to run the correct git config command to add it manually. More information on filters can be found here.

Lastly I created a new .gitattributes file within the root of the repository and give it the following content:

/src/Umbraco/Web.config	filter=umbraco-config

This is where you specify which files to apply the filters to. More information on gitattributes can be found here.

What next?

There is actually one more step, but this is one that everyone has to do when they clone the repository. Ensure it's the first step in your readme: git config --local include.path ../.gitconfig. This tells git to include the committed config, as it doesn't do this automatically.

Doing this has ensured the repository has remained clean of any local developer config making it super easy for a new developer to pull down and get started, or for a fresh deployment in a new environment, without any intervention.

Posted on Saturday the 14th of March 2020