Separation of Concerns with Git

7 Aug 2016

When developing a web app or site that has a public-facing repo, there may be a need to have some rudimentary separation of concerns where git is concerned. Certain files that we may want on the production server might seem out of place on the public repo due to licensing, privacy or security concerns.

This method presumes that there are three repos: production, public and local/development. We will be attempting to prevent some sensitive files from being pushed to the public repo, while allowing them to be sent off to produciton.

To solve this problem, we first add dummies of the sensitive files to the development repo. These dummy files can be empty files, as long as they have the same names as the actual sensitive files we will eventually add.

We will commit the dummy files, then replace them with the actual sensitive files. Now we tell git to assume that the files we have just added have not changed.

This initial setup can be accomplished by running the following commands in the console:

NOTE:/path/to/actual/sensitive_file must be in the .gitignore or outside of the git project. Otherwise, it beats the point of this whole process.

From now on, git should skip over the sensitive files whenever it is checking for diffs. Thus, we can push normally to the public repo where the dummy files reside, while the actual sensitive files remain in our development repo.

To push the sensitive files to the production repo, we will take the following steps:

Tell git to no longer assume the files are unchanged.

Commit the sensitive files, and push them to production.

Tell git, within the scope of our development repo, to go back one commit. Essentially, we undo the previous commit, but only locally.

Remind git to assume the sensitive files have not changed.

These 4 steps can be packaged into a script, which we will run whenever we want to push some changes to production.

An example script is presented below, with the following assumptions:

We have some licensed web fonts that we shouldn't distribute on our public repo.

We want the font files to reside on the same server as our web app/site rather than on a dedicated font server.