I am working on a Drupal theme. I am going to be using "intermediary" languages to develop it, ie Stylus for styles, and CoffeeScript for some of the front-end scripts.

I am going to be using a git hosting service to be able to share the code among colleges. I am also going to be using it to update the code locally and then push onto hosting service, to be later pulled by the live drupal site.

This makes things really elegant.

However, I have noticed that a lot of developers tend to .gitignore all compiled code.

If it were a good practice, I would've loved to follow it, if and only if there wasn't this one issue: recompiling all the code that is needed in order for the theme to work out correctly.

This means that when I do a pull, I will have to recompile all the CSS and JavaScript code. Now, if I were to do a pull on the live site, there's a risk that a user goes to the site right at the moment I do the pull. No styles and scripts will be loaded on the user's end, so long as the code hasn't compiled.

Of course, compiling takes about a second, and the user might probably think to him/herself "meh, it was just my internet connection."

But there is also the issue that the server doesn't have the compilers installed to begin with. So now, I would do a pull, but there will be no styles, and no scripts.

Is it an absolute must that I delete all compiled code, or can I go ahead and include them in the commit?

  • Having a lot of generated files will mess up your commit information. Go back and look at your old commits and see how much it matters.
    – user1249
    May 2, 2012 at 7:38

2 Answers 2


Yes, you must delete all compiled code. Source control is for, well, the source code, not the compiled files. The worst scenario is when developers commit the compiled binaries. Your case is not the same, since you're not committing large binaries which are diff-unfriendly, but still, keep your source control free of everything you don't need to run the application.

What seems wrong in your case is the deployment process. Instead of pushing the code to the production server directly from the source control, you should rather, in the simplest case:

  • Load the source code,
  • Compile and/or optimize it,
  • Push the compiled version to the server.

If your website has lots of visits, you may need a more complicated flow, using two servers, for example:

  • Load the source code,
  • Compile and/or optimize it,
  • Push the compiled version to the staging server,
  • Run a bunch of tests to ensure that the website is working on staging server,
  • Forward all the requests to the production server 2,
  • Once the production server 1 doesn't have any requests, push the compiled version to it,
  • Forward all the requests to the production server 1,
  • Once the production server 2 doesn't have any requests, push the complied version to it,
  • Use server 1 and server 2 again.

MainMa's answer is great but it should be noted that this is a prime case for continuous integration. Setting up a machine (either a hosted solution or one of your own) that will identify when a commit has come in, compile the code, run appropriate tests, and build the deployment package if the tests succeed. This approach could be taken a step further and automate a scheduled deployment when your criteria for a deployment has been met.

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.