TL;DR. Git provides better control of website changes than manually tracking file versions and it’s free.
I decided to build my portfolio website from scratch, just to practice my HTML and CSS skills. It’s always better to practice on something real, and I’m relatively happy with it. It does what I need it to do right now, but I periodically need to add content or make improvements.
It only recently occurred to me to join the two endeavors (duh!) and use Git to provide local version control as I continue developing my website. Local version control is only a tiny fraction of what you can do with GitHub, but it has some nice features and is a good way to become familiar with Git.
Why do I use it?
My system of version control has always been to make backup copies of files as I’m working on them, using dates and numbers to differentiate the versions. This approach clutters up my file system, but it makes me too nervous to work without backups.
Git handles all the hard work of version control behind the scenes. I can easily create a copy of my entire website and make changes, accept or discard changes, without ever touching my live copy. In fact, I can have multiple working copies of the website – one to make small changes and one to test a major restructure – and easily switch between them. Furthermore, if you write good messages, Git’s log shows useful descriptions of the changes. Git can even revert to earlier versions of your files, if necessary.
If you are not familiar with Git, you can get a feel for it by going through the GitHub tutorial. (GitHub is one of the Git hosting services.) I also took two online classes from Lynda.com, which I highly recommend: Up and Running with GitHub and Git Essential Training.
I downloaded the GitHubDesktop which installs Git. There are GUI interfaces, but other people recommend and I agree that using a command line interface is a good way to learn the commands. So, I use Git Bash which you get when you download Git for Windows.
How Do I Use It?
First, I use the command line to tell Git which version of my website I want to work on: the master copy or the development copy. For this example, I want to work on the development copy. Then I change, add, or delete files. When I’m done with the file changes, I use the command line to tell Git to add the changes to the development copy. When I’m completely satisfied, I tell Git to add the changes to the master copy, which I then FTP to the web server.
If I’m in the middle of working on a website upgrade, but notice something is wrong with the live website, I can use Git to fix the live website without disturbing the work I’m doing on the development copy. I do this by creating another copy of my website called fixes. Then I tell Git I want to work on the fixes copy. I make the changes to the files, add them to fixes, test them, and then add them to the master copy, and then FTP the fixes to the web server. My live website is now fixed. I tell Git I want to work on the development copy and I’m back where I was.
As I hope you can see, Git keeps track of all the nuts-and-bolts of the changes while you keep track of the big picture. In my next post, I’ll go into more detail about how I use Git to make website changes.