pedrotester
pedrotester

Reputation: 189

Git ignore compiled CSS but keep the latest version for production-ready state

I used to commit my compiled minified CSS files to the repo, then I realized each time, the entire file is sent since it's minified on a single line. So it means for each small modification, I save an entire CSS file in my history and it will quickly add up for no reason.

Can we ignore the CSS files compiled automatically by my Text Editor from a LESS file?

If I put these CSS files in .gitignore, they won't be in the repo but I also use the repository to immediately get a working website.

I always compile the LESS files from my local computer and I want to keep it that way (so don't suggest me to use Grunt or something to automatically compile when a user loads the page, please :P).

The ideal solution would be to only keep the latest file in the repo for CSS files only. For history I'd check the LESS files. The CSS files would be there only to make the site works right after a git clone/pull.

Upvotes: 2

Views: 2150

Answers (3)

LeGEC
LeGEC

Reputation: 51962

  • don't commit the css file in git
  • don't use git push as a deployment script
  • do write a separate deployment script, which packs your code and the minified css from your local computer, and copies that to your production server

As far as sending files over a network go, if git can do it, scp can do it too.

Upvotes: 1

Colin D Bennett
Colin D Bennett

Reputation: 12104

The key is to distinguish between versioned source files, and the resulting build artifacts.

The LESS files are source files and belong in your Git source repository. However, the generated CSS files are a product of the build process, and are a build artifact, just like a Windows .exe/.dll or Java .class files.

Build artifacts should not be committed to the source repository for several reasons, including:

  • adding noise to the version control history, with commits updating the generated files
  • causes additional merge conflicts when branching/merging is used
  • does not work if you want to use .gitignore to ignore files; if a file is committed to the repository, it will not be ignored, and changes will be displayed

Best practices generally isolate build products into a specific subdirectory of the project root, such as build, or output, or bin, where all build artifacts are stored. This single subdirectory can then be added to .gitignore.

Your automated build process should be making the build artifacts available for deployment or download. But these artifacts won't be committed to the source repository.

Upvotes: 3

Brian Dunne
Brian Dunne

Reputation: 135

Let me see if I can sum up your requirements here:

  • The end user should receive minified CSS when they access your server
  • Your server uses your git repo as its code source (hopefully a Master or Production branch)
  • You don't want a lot of minified CSS history in your repo
  • You want developer-readable CSS history in your repo

These are pretty common requirements. Most people are using deployment scripts to perform actions like these consistently on each production push - one script that they can fire on the server to download the source from the repo, minify all CSS/JS/HTML, update your package manager with any new requirements, reload any local services that need reloading, refresh/warm up caches, etc. This can be a simple web service that you write and then call via a hook from GitHub/BitBucket/whoever on a push to your production branch, or you can use a deployment framework specifically built to help you deploy reliably.

If you're coding in a mature framework, there's likely already some deployment tooling out there that you could take advantage of with minimal effort. If not, you'd have to search for something language-specific if you didn't want to write it yourself (depending on how much work you need to do on the server aside from copying the repo and minifying, writing a webhook yourself might be the quickest and easiest solution).

Upvotes: 6

Related Questions