Source Control with Git

Thursday, October 16th, 2008 at 11:36 pm

I’ve been using version control for various projects for quite a while now. Basically, it lets you (and your co-developers) track your changes, who added what, merge conflicts, as well as going back in time and reverting your code base to its previous state.

Typically (in Subversion and CVS for example) you will have a central server which all the developers check their code in to. For a project not too long ago I was required to learn git, a distributed version control system. There were a number of reasons for doing so, but the most important (well, in my opinion) are:

  • off-line repository access – we can work on our code changes and check in, even if we don’t have internet access.
  • local repository – I can make as many check-in’s and changes as I like without interrupting or checking in potential conflicts with other people’s code. Also, I feel more free to check-in experimental code without the concern it will disrupt anyone else.

There are a few distributed version control systems (D-VCS’s) that are currently being actively developed and used. Bazaar, Mercurial (hg), and Git seem to be the most prominent at the time of writing with Git and Bazaar both gaining steam. Personally, I have chosen to migrate my personal projects over to git from svn due to my familiarity with the system now.

Quick start:

this will create an empty directory and initialize a git database

mkdir test
cd test
git init

now, create a text file and add some text

vi hello.txt
hi, I am file version 1.0

next we need to tell git to track this file and any changes that happen to it

git add hello.txt

at this point we can check the status of the repository by issuing a

git status

and you should see something like

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#    new file: hello.txt
#

This tells you that you’re currently on the master branch (more on branches in another post) and that this will be the first commit to the repository. The next few lines will list the files that have either been added, changed, or removed since the last commit.

Now you can issue a

git commit .

to commit everything in the current working directory. Git will ask you for a comment to let other deveopers (or yourself if you’re forgetful like myself) know what changed since the last commit.

Now you can keep making changes, adding / removing files and committing as often as you would like. Running the comment

git log

will output a list of all the changes that have been made

Prior to committing a file, it is sometimes handy to compare the current file with the previous one. This is accomplished with

git diff hello.txt

The real power of git comes into play when you clone someone else’s working repository. To try this out, go to www.github.com and find a random project and click on the clone URL and copy and paste the command (ie: git clone git://github.com/rails/rails.git to clone the ruby on rails source code). This will pull down not just the latest copy, but all the history and changes that have been made to the project to your local machine. You can now make your changes, and if you have permission do a

git push .

to push your changes back to the server you downloaded them from (hence the term distributed).

If there is interest, in the future I will do a series on tagging and branching and how to use them to keep an organized, stable set of code, while making major changes in a safe manor as well as some graphical tools which can make your life easier while trying to merge changes / fix conflicts.

Tags: , , ,

Comments are closed.