Version Control is more important, more useful than people seem to realize. Many programmers understand its importance, but still don’t bother with it. Consider this scenario:
You are a small company that makes widgets. The software that controls the widget maker is changed from time to time, small upgrades here and there for usability or maybe a major bug was found. The code is solid, backed up, and safe. This is great but you’ve switched programmers a few times, and the software included with your awesome widget maker is different across several clients. Changes and enhancements that are included in Widget Maker mark III need to be given to the clients who are using the mark II, but what parts of the code are specific to the mark II or III, what parts can be safely copied or used, when did we make this change or that change and why? Was this piece of code for problem X on the mark I? How do we do this without just tossing it all out the window and writing fresh software for the mark IV and spending countless dollars and untold hours?
This extreme (and slightly silly) example highlights where a version control and source code management system could be useful. Wouldn’t it be great if you could look at the software the previous programmer had released for the Mark II, check out the enhancements for the mark III and merge the two together into a cohesive update? Maybe look at a code timeline of fixes? This is where software packages such as Sub-Version, Team Foundation Server or GIT come into play. Let’s take a look at the one I tend to prefer, GIT.
GIT
Git isn’t the easiest version control system out there, but it’s one of the most powerful and hey the price is right. (Free, Open Source). It came from the Linux world and is extremely powerful. While it exists mainly on the command line (CLE) it also has some decent GUI options as well.
Getting Git: http://git-scm.com/downloads
From your OSX, Linux, Solaris terminal, or if Windows the Git Bash Terminal (Start/Programs/Git/Gitbash)
git config –global user.name “your name”
git config –global user.email your@email.address
This will setup your local git for identifiable check-ins which is useful when you have multiple programmers, but still important if you’re coding solo.
Initializing your first repository
Each project you want to keep under control is a repository. Setting one up is pretty simple. From your terminal change directories to your new empty project folder and issue the initialize command.
cd /var/www/vhosts/danflood.com/httpdocs
mkdir myproject
cd myproject
git init
Ok! End of article you’re all done.
Well, ok so that’s not so useful… let’s add the files we’d like to start controlling. You can copy in your php scripts easily enough but then you have to let Git know about them. You can add each file one by one, which is useful if you’re not that organized and have non-project stuff mixed in…
git add myfile.php
git add thisfile.php
but let’s assume you have your files all neat and tidy, so you can issue a simple
git add .
Now that we’ve told git about our files, let’s COMMIT them
git commit –m “my first commit and this is a detailed comment!”
It makes sense to put as much detail as you can in the notes, or at least reference a document that explains the changes in this commit.
So your local git repository is all set up. You do have some reading to do but you are setup and ready to go. You are, however, just local. We also want to have a remote centralized git repository that can be accessed by others and provide redundancy for you – because let’s face it you’ll drop your macbook in the pool or something and then where will you be?
For remote centralized Git with a GUI I’ve looked at Gitorious and Gitlab, ultimately deciding on Gitlab. Setting up Gitlab is an article of it’s own, but assuming you have a remote GIT all setup and ready to go you need to connect to it from local:
Git remote add origin git@mygitlab:username/myproject.git
Git push –u origin master
In short you should commit as often as you can, not just on special occasions or when you’re feeling particularly happy with something you’ve done – you never know when you’ll need to return to an earlier time in your code and you’ll be happy that your previous commits are there!
Recent Comments