I use Gulp to generate minified CSS from my SASS code for a project I'm working on.

I wondered whether it's considered best practice to regenerate this minified CSS when pushing live from Git...


To store the minified CSS files in Git so they are automatically pushed live to production without further work on the server's part?

I'd appreciate people's ideas on this. Thanks!

  • There's only one place minified css/js/etc. should be stored: /dev/null. Commented Aug 31, 2016 at 2:31
  • (That's because your webserver is perfectly capable of using gzipped transport.) Commented Aug 31, 2016 at 2:35
  • Storing both compressed and uncompressed CSS means you now have two versions of the same thing. Which is the canonical version? Its easy to envisage the scenario where one dev updates the compressed CSS and another updates the uncompressed CSS. Your two assets have now diverged. Of course process should prevent this but its a realistic prospect with for example a new developer on the team.
    – Qwerky
    Commented Sep 7, 2016 at 17:06

2 Answers 2


"It depends." For normal development tracking, no. For cloud and DevOps deployments, however, it's often convenient, or even required.

Most of the time, @ptyx is correct. Indeed, his "no" could be stated somewhat more emphatically. Something like "No. No! OMG NO!"

Why not store minified or compressed assets in source control system like Git?

  1. They can be almost trivially regenerated by your build process on the fly from source code. Storing compressed assets is basically storing the same logical content twice. It violates the "don't repeat yourself" (aka DRY) principle.

  2. A less philosophic but more practical reason is that minified / optimized assets have very poor compressibility when stored in Git. Source control systems work by recognizing the changes ("deltas") between different versions of each file stored. To do that, they "diff" the latest file with the previous version, and and use these deltas to avoid storing a complete copy of every version of the file. But the transformations made in the minify/optimize step often remove the similarities and waypoints the diff/delta algorithms use. The most trivial example is removing line breaks and other whitespace; the resulting asset is often just one long line. Many parts of the Web build process--tools like Babel, UglifyJS, Browserify, Less, and Sass/SCSS--aggressively transform assets. Their output is perturbable; small input changes can lead to major changes in output. As a result, the diff-algorithm will often believe it sees almost an entirely different file every time. Your repositories will grow more quickly as a result. Your disks may be large enough and your networks fast enough that isn't a massive concern, especially if there were a value to storing the minified/optimized assets twice--though based on point 1, the extra copies may be just 100% pointless bloat.

There is a major exception to this, however: DevOps / cloud deployments. A number of cloud vendors and DevOps teams use Git and similar not just to track development updates, but also to actively deploy their applications and assets to test and production servers. In this role, Git's ability to efficiently determine "what files changed?" is as important as its more granular ability to determine "what changed within each file?" If Git has to do a nearly full file copy for minified/optimized assets, that takes a little longer than it otherwise would, but no big deal since it's still doing excellent work helping avoiding a copy of "every file in the project" on each deploy cycle.

If you're using Git as a deployment engine, storing minified/optimized assets in Git may switch from "no!" to desirable. Indeed, it may be required, say if you lack robust build / post-processing opportunities on the servers / services to which you deploy. (How to segment development and deployment assets in that case is a separate can of worms. For now, it suffices to know it can be managed several ways, including with a single unified repository, multiple branches, subrepositories, or even multiple overlapping repositories.)

  • 1
    Thank you for this! Much appreciated. I've marked this as the answer instead as it seems a lot better explained. Commented Aug 30, 2016 at 23:14
  • 1
    git does not store only deltas. SVN does, but git uses a much more complex mechanism for storing files. Some people tell you it stores a full copy of every file, but from what I understand, this is also incorrect. I won't try to get into what it does do, since I'm not fully clear on it myself.
    – jpmc26
    Commented Aug 31, 2016 at 0:49
  • I think you could achieve the nuance just by changing, "and store only the new deltas" to something along the lines of, "and use these deltas to avoid storing a complete copy of every version of the file." That would make your point, be factually correct, and avoid delving into the issue of how it's done for any given source control system.
    – jpmc26
    Commented Aug 31, 2016 at 1:40
  • Could DevOps just use git hooks to automatically trigger minification on the deployed server, getting the best of both worlds? Commented Apr 19, 2017 at 6:24
  • 1
    @ButtleButkus Depends on the on the deployed server. To depend on post hooks you must either 1/ assume the appropriate transpilers, minifiers, and optimizers are present on the target, or 2/ load them before running the post hooks. 1/ is dicey. 2/ imposes a load cost / latency on every deploy. It also introduces new possible failure modes and a requirement to debug post hooks in an remote, opaque, transient environment. Not ideal. So hooks aren't a silver bullet. Pre-converting/optimizing assets may be inelegant, but it's robust and pragmatic. Commented Apr 19, 2017 at 6:33


Source control should only contain source. If it's generated from source, it doesn't belong there - and should be generated by your build process.

The fundamental reason you don't want to source control intermediate build artifacts is that if you do, it gets really hard to trust wether what you're running comes from the source you just modified, or from an intermediate product that you failed to rebuild.

  • 3
    Think of generated code the way you think of executable code. Commented Aug 30, 2016 at 21:15
  • 4
    This principle is not always true. If you have files that are generated with heavyweight tools you can't expect a user to have, it may make sense to put the generated files in git. Many people even put generated autoconf configure scripts in git for this reason. Commented Aug 31, 2016 at 2:34
  • @R..: Ideally, you maintain a separate artifact repository for those things, but reality is rarely ideal.
    – Kevin
    Commented Aug 31, 2016 at 3:48
  • @R you can compromise - but it's just that. And in the case of CSS minification, I don't think the tools qualify as 'heavyweight' or 'slow' or 'inconvenient'. Also, there are alternative dependency injection mechanisms (maven, ivy...) that work well and don't require you to put generated code in your source control.
    – ptyx
    Commented Aug 31, 2016 at 16:45
  • 1
    @ButtleButkus I don't have a lot of expertise on the devops case. What I've seen is git used as a (very convenient and flexible) transport/release/deployment mechanism, rather than purely as source control. Unless the 'source' git and the 'delivery' git are separate (separate repos or separate branches), this means you have to compromise the source->build->deliverable chain somewhat - e.g you'll end up with production having source code and extra branches lying around, and development with unused binary products. It's a pragmatic compromise, but I prefer separating concerns when I can.
    – ptyx
    Commented Apr 20, 2017 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.