问题
I recently started working with LESS, and as I did some research to automated builders like Jenkins and Grunt, it seemed a common piece of advice was not to store LESS files on the repo, or not to have them on the live server, just the compiled CSS.
So I was hoping to get some advice on this. It seems that as LESS files are part of the project, storing them is necessary. But it makes sense not to have extra, random files on the live server. Deleting them myself seems the wrong way to do it every build, plus time consuming. I assume I can get automated builders to do it for me, though I don't yet know how. The most straight forward way would seem to be to not pull them down in the first place.
Or am I thinking about repos the wrong way? Should I have a different file storage medium for storing the LESS files, and others? I already don't store my PDFs on the repo, should I treat LESS the same? How should I store these files?
回答1:
The conflict comes from aggregating source management and release management: you are using the same referential to:
- store sources (from which you can build releases, included the compiled CSS files),
- and to deploy (part of the release process)
The article "The Ideal LESS Workflow with git" suggests a pre-commit hook to make sure the css are always in sync with LESS changes, but that means storing generated content in the git repo itself.
I would rather:
- push to a bare repo
- have a post-receive hook which would:
- checkout that bare repo in the target folder (the live site)
- build the compiled css (compressed with lessc)
- remove all less files
来源：https://stackoverflow.com/questions/25497828/git-storing-but-not-pulling-less-files