Question

So I’ve been using git for the first time, and there is a scenario that I don’t quite know how to solve.

I’ve got a simple webapp (only html, css and js), and I want to produce regular releases that can be tracked with a version number. This is easy to do with git tag. But the catch is that for my releases I want to do some extra things, like minifying the js scripts and updating the html pages to point to them. Also, I need a .gitattribute in the release that ignores the non-minified js scripts, so that git archive produces the smallest possible output.

What I’ve done is creating a releases branch. This branch includes the aforementioned .gitattributes, and the modified html pages. Each time I want I new release, I switch to this branch, merge the changes from master, then finish the release and tag it with a version number. It seems to work as I want, but I’m not sure how this is supposed to be done.

My question for the more experienced git users is how is this case handled usually?

Answer 1

The branch solution is a good one, but for release management, you could also simply store a “release” in an external repository (like a Maven one for instance, or another Git repo declared as a submodule)

The thing with release management is:

• you don’t need a detailed history for each file (since those files are build from sources files)
• you need those “release” files to be “packaged” like the minified js.

For those reasons (build and packaging), you don’t have necessarily to keep them in the same repo than the one used for sources (with its detailed history and multiple branches).
You simply don’t produce releases version at the same pace than you do for sources: the development lifecycle is quite different from the release one.