Up until now, we’ve been making code changes locally without using any sort of version control. With the complexity of this site rising, that’s becoming more and more irresponsible. What changed and when? Why did it change? How can we see what it was before in case it causes problems we only find out about later?
There are so many good reasons to use version control that it’s almost outside of the scope of this series, but suffice it to say, we’re going to use it. It solves all the questions I outlined above.
In our case, I am already using version control on CSS-Tricks. I use Git and host the repository on Beanstalk. Beanstalk takes care of deploying the site through FTP. The setup is mega simple. For CSS-Tricks I don’t even have a staging server I just push everything right to production.
I use the Mac app Tower to work with Git. If you want a full screencast on how to get that all set up from scratch, I have that available here.
We make a little change and you can see the change show up in Tower as a “dif” (where you can see what line changed and how). Ultimately we take our static design we’ve been working on so far and make it a subfolder on the real deployed CSS-Tricks.com – then go look at it. Yay it works! Well, for the most part. Now that the design is in a subfolder some of the links are broken but that’s no big deal.
I should note that I don’t return often enough to show myself commit files to Git in future videos. Just imagine that at the end of each video I bounce over to Tower, select relevant groups of files and commit them with a lovely descriptive commit message (which is what I actually did).