For example, if you change a variable that defines a color used in many places, your history will show that change not only but also all lines of CSS where he changed that value. Then, review past changes becomes much more difficult to easily determine what changes are relevant (the change in the source file LESS / SASS) than not (all lines modified in the resulting CSS).
Therefore, a best practice is versioned LESS / SASS files but not the resulting CSS, since the latter is only the product of the process of compilation of sources.
To make your CSS accurately reflects changes in LESS / SASS, you can automate the compilation with a mixture of tasks Grunt and git hooks.
Git Hooks
The git hooks allow you to execute actions to certain events related to version control, for example, when you commit, share changes (push), receive updates, etc.
The scripts that are executed are specific to each repository, which although a bit difficult to share (although this just another folder in your project) to define separate tasks of development and production flows. For example, you can generate developing CSS without minimize and Sourcemap while in production use without Sourcemap minimized versions.
As it comes to shell scripts, you can run almost anything that has a command line interface, but in particular, I find it especially useful to run tasks Grunt.
For example, this is the script I use in the post-merge hook on a project in development
It Is Pretty Simple:
- Detects whether there is any change in any file .less front / less folder or any of its sub-directories among the latest work (ie, "my" version) and the last version I am entering
- If there are changes, run the command grunt less: development, corresponding to a defined task with Grunt.
This same principle can be applied to keep out of version control all the resources that are managed with a package manager (Bower, NPM, Composer), in order to maintain a neat and very fast to clone the repository.
