The bigger the project that I undertake, the more of a risk and sometimes a pitfall, that I fall in to. Often when developing code alone, you fly about, trying different bits of code and usually making snap decisions on which method to go for. At the time you think that it’ll be fine to work like that and it won’t cause any problems.
This is fine if you find there are problems early on, but if it’s not until days or weeks down the line, and you realise that you should’ve made the opposite decision, then you’ll have to try and figure out just what went wrong, and where and what you did differently to make things work.
Upon doing this for yet another project recently, I decided it’d be the last time it happened, and promptly looked into version control software, which I’d previously never thought about, assuming it was software only useful for team development.
I found many different options I could use, including CVS and SVN, both of which appear to be widely used throughout the industry, however what I ended up picking was Git, another well know name, which is newer than both CVS and SVN.
Git differs in the way that it works, allowing for offline development, rather than having to work on one set of files (usually stored online), as SVN and CVS do. Because you work on your own set of files, it also makes things much faster too, which is always a plus when you have to add extra steps into your workflow.
Git also seems to get high recommendation from the web development community especially and is also used for many large scale projects.
One of the best things about Git is the accompanying software that is written to work with it is generally open-source and free, which certainly is useful for a poor student.
With Git having everything going for it, I decided I should give it a try and see how I got on with it in my workflow.
Finding a Git GUI
Git by itself is just a command line only tool. This makes it very versatile but for a web developer’s environment, it’s not the most convenient option to use.
However, many free GUI’s are available to work with Git. The problem I found with many of them was that the free version had reduced functionality (only one repository) or it was heavily linked to a certain repository provider. Many also had an interface that didn’t work with me and over-complicated things. After searching around for both an online repository finder and a good GUI client, I finally settled on using BitBucket and SourceTree, both these websites suggest each other as counterpart services, and as BitBucket had a lot fewer restrictions on the free account, it seemed like the way to go.
Using the two services together, it made it very easy to add Git repositories to SourceTree (dragging and dropping the link from the website) and clone the repository so you can start work on the files whenever you want.
Once you drag in the remote repository, you can choose a place for the local copy of the files to be stored, if you are uploading an a project that is already in development, this will be the folder where those files reside.
With all this set up, you can now open the project view. SourceTree will automatically detect files which are in the working directory but aren’t in the repository (or which haven’t been updated on the repository since an edit has been made). To add these files to the repository, you can simply select them all, and right-click > “Add to Index”, this will begin tracking these selected files in the local repository.
When you finish a development session, or you feel that it’s a good point to save a version, you can click the “Commit” button, in the toolbar. This will make a version of the files in your local repository, but this will not, by default, synchronise your local repository with the online repository. SourceTree makes this possible with the “Push commits immediately…” option at the bottom of the commits screen. This makes the process a lot simpler, faster and cleaner and takes away some of the complications and confusions that are sometimes related to using Git.
One of the best parts of SourceTree, is the way it shows changes and project progression. Changes between versions are clearly highlighted with red and green highlighting, with comments for each commit shown next to it.
So far I’ve found that the whole process fits in well with my work flow, and making a new version of a project generally isn’t a complex process.
Since starting using Git with projects, I have been a lot happier deleting and throwing about code, knowing that I won’t regret it later on, because I’ll have a version of the project before I made the change. It’s something I’d certainly suggest to anyone working on even the simplest of websites.
Version control within IDEs
When I initially looked into version control, there was an abundance of version control options that were integrated into IDEs, however when I tried these I generally didn’t like the rest of the program, despite getting along with the version control integration. For this reason, I decided I wanted a stand-alone system, where I could edit the file even with the simplest text editor up to a full IDE, and still be able to make a version of the file after making changes.
For what it’s worth, Aptana, built on the popular Eclipse IDE, is a web technology focussed IDE, with good version control compatible with several different version control systems.
↬ Git homepage – Information about the system, and a download link for the command line toolkit.
ᔥ Smashing Magazine’s Version Control System review – An article that gave me a lot of insight into the popular options of version control systems.
ᔥ BitBucket – BitBucket, online Git and Mercurial repositories with a free account.
ᔥ SourceTree – SourceTree, a GUI Client for Git on Mac.