git/hooks/post-merge but, as I mentioned before, I wanted it to be tracked under version control. If I wanted to I could certainly have put my entire recompile_sass script into.
Since I wanted to explicitly declare which Sass files to compile and their resulting filenames and keep this script under version control, I chose to put my calls to the Sass gem in a bash file within my repository:īash wp - content / themes / grunwell2012 / utilities / recompile_sass
This means that by tying our SASS compilation into the post-merge hook we can be certain that our CSS files will be generated if and only if something has changed in the repository. if you receive the “Already up-to-date.” response after performing a git pull, your hook will not run). For this reason you may find it easier to store heavier scripts that you want in every copy as a separate file (bash, ruby, perl, etc.) within the repository, then execute this script from the corresponding hook script (as you’ll see in our example).Īccording to the manual, the post-merge hook fires when a git merge is invoked on a repository (generally speaking, git pull is the same as a git fetch followed by a git merge) and, in my experience, only when updates have actually been made since the last pull (i.e. Git hooks are only stored in your local copy of the repository and will need to be reconfigured for each instance of the repo.
In this case, we’ll be using the post-merge hook, found in.
#SERVER FILEWATCHER TO RECOMPILE SASS CODE#
You can use git hooks to do things like validate commit message formatting, strip trailing whitespace, email someone whenever code is deployed, etc. Git has a nice little feature called “Git Hooks” which allow us to execute scripts at different points throughout the repository lifecycle. Automatically recompile our Sass upon deployment For that reason I’d recommend blacklisting the generated files instead of whitelisting the non-generated. If you’re using a third-party tool/framework/library that has its own stylesheets (for instance: WordPress) you’ll need to explicitly allow those styles into the repo. gitignore file will allow that file to be tracked): If you want to be a real hard-ass, you could add *.css, but if you go this route be sure to let in any CSS files that aren’t generated by SASS ( remember: adding a ! before a rule in the. gitignore file and explicitly excluding the generated files you want to block. This should be as simple as updating (or creating) your. Keeping generated files out of the Git repository
Generated files are explicitly blocked from the repo (to prevent someone who doesn’t know any better from committing them).In order to do this, we’ll need to make sure of a few things: This technique has one goal: keep generated CSS files out of the git repository.
#SERVER FILEWATCHER TO RECOMPILE SASS UPDATE#
What would happen if a developer who had never used Sass needed to make an update to a site? How long would it be before someone starts complaining that the change they made to the CSS file was overwritten after the next compilation of the corresponding. When you’re working in a team environment however, it’s necessary to consider that several developers of different experience levels may touch a site throughout its lifecycle. When you’re the only one working on a site, compiling Sass files locally and committing the generated CSS isn’t the worst thing in the world. As I wrote about the other day, my site’s styles are written using Sass, a Ruby-based CSS pre-compiler.
0 kommentar(er)
