The basics of git (or at least how i’ve been using it)

A while back I wrote about how I use subversion (SVN) version control as part of my workflow, when working alone and as part of a team. I’ve observed many of my friends and colleagues dropping SVN and moving onto GIT, and used it when working on swoop patagonia but personally carried on using SVN as my default preference, in a “if it ain’t broke don’t fix it” kind of way.

However, this has recently changed, having learned a bit more about it using it as part of the workflow at my new gig at potato, I can’t see me creating any more SVN repos by choice. So here is how i’m using it – note this is very basic usage – i’m far from an expert at this point.

The basic setup is similar to how i’ve been using svn:-

1. Create a repo on a remote host (e.g. github/unfuddle/my own server)
2. Check it out to my local machine (in git terminology “clone” it)
3. Make some changes, add some new files, delete files
4. Commit changes back to the remote repo (in git you commit locally, then push the changes back to the server)

To clone the repository to your machine:-


git clone https://your/repote/repo


To add new files to it:-


git add /your/new/file


To see the status of your local repo


git status


To commit changes (this is where SVN users get confused), first “stage” your changes:-


git add /the/file/you/changed/or/added


Then commit (note this just commits it locally):-


git commit -m 'message here'


or to add a commit message using your default editor:-


git commit


So at this point you haven’t sent anything back to the remote repo, you can carry on making changes and committing locally (this is one of the advantages of GIT over SVN). When you are ready to update the remote repo:-

First pull down any changes from the remote repo (assuming you are still on the master branch – i’ll come to branching later):-


git pull origin master


At this point if there are any conflicts you will need to resolve them, which is usually a case of editing any conflicted files, then adding and committing them. Then you push:-


git push origin master


So this is basically not far off how I used to work with SVN – the only difference being that I have a local change history, so (in theory at least) I can roll back changes if I get into a mess.

Where it gets more interesting and useful is where you introduce branches. I know SVN has branching, but i’ve mostly ignored it, but with GIT i’m always creating branches, which i’ll cover in another post..