The basics of version control using GIT Part 2

Following on from last weeks first part we continue our look at using GIT

Configuration of GIT

Before going to far into the command usage of GIT, it is a good idea to first configure your preferences. The two main items that need to be configured are the user name and email details.

These details are not setup for authentication, but more of a responsibility point of view, if you do need authentication (i.e., if you eventually decide to use a central server as well) then you have a few options, most people just use SSH to authenticate.

To configure the two variables for your local machine run the following commands :-

git config –global “Joe Bloggs”
git config –global “”

These commands are pretty straight forward, the first just creates your username that will be stored inside the repositories when you commit any changes, and the second command just applies your e-mail address information.

Basic Git Commands

If you currently have a folder stored on your machine containing your source code, setting up a local GIT repository is very straight forward, you can do this with the following command :-

git init

this creates and initialises an empty git repository for your source code and places a single hidden .git folder in the root folder of your project, this is a much better and cleaner way than subversion for example which places hidden .svn folders in many locations within a checked out project which can get very messy very quickly.

git status

this shows the current status of your git repository, when you run this command you should see output similar to the following :-

# On branch master
# Initial commit
# Untracked files:
# (use “git add …” to include in what will be committed)
# index.php
# sales.html
# sales.php
nothing added to commit but untracked files present (use “git add” to track)

As you can see the information that GIT displays back to you from the command line is very helpful and makes learning the system very easy, in the example we have used above we can see that we have three untracked files, and it even displays to us the exact command that we need to enter to add these files to the repository.

git add

This command will addto the index (also known as the staging area), so in our case, as ours is currently empty, we want to add all files that are currently untracked. This can be done with the command :-

git add *

If you now run “git status” again you can see that all the files are now being tracked and are staged and ready to be committed :-

# On branch master
# Initial commit
# Changes to be committed:
# (use “git rm –cached …” to unstage)
# new file: index.php
# new file: sales.html
# new file: sales.php

This information shows the same files again, but instead of showing them as “Untracked files” it now displays them as “Changes to be committed”, which basically means that the files are being tracked and are ready to be committed to your local repository, this is known as “staged”.

With GIT developers have the ability to use a staging area, this allows the developer to store up all the changes in a single place which are then committed to the repository once they are happy with all the changes, the best way to think of the staging area is almost like a loading dock, the files are almost ready to be sent but have not quite yet been loaded onto the truck.

Once the files have been added to the index (staging area) the files are then ready to be committed, which can be done with one simple command :-

git commit -m ‘initial commit of the project’

Viewing all the repository commits.

If you want to double check that your commit has been done correctly, you can use the command :-

git log

this will show you details of the most recent commits on the repository, you can also use the following command to get the same result but in a more condensed manner :-

git log –pretty=oneline –abbrev-commit

the output should look something like this :-

60ae962 edited the sales page with new prices
ebef7a9 initial commit of the project

the first part of the output is an abbreviation of a 40 character SHA-1 hash which is simply used to identify the commit, however abbreviating is generally fine since it’s just as easy to identify the commit with 7 characters as well as 40.

Closing comments

This is only scratching the surface with GIT and while it is quite simple to learn, there is quite a lot of detail based on the fact that GIT is so powerful.

GIT is able to push/pull changes to/from a central repository, ignore certain file / filetypes, allows branching, merging, tagging, and much more, but getting started with these basic commands is a great place to start.

This entry was posted in Development. Bookmark the permalink.

Comments are closed.