With 3 long-running tasks concurrently on my plate, I finally got around to learning branching in git, and it’s easy!

Until this week, I had managed to get by without learning to branch. I have looked previously but got a little lost. I often temporarily stored my work using “git-stash” to work on multiple things at once, but this is very limiting.

So, Here we go. My basic workflow now look like this.

Create a new branch (based on the HEAD of your current branch), and automatically switch to it:

git checkout -b my_branch

Then you can work within this branch as you always would.

Work, work, work…

git add files_i_have_edited.txt
git commit -m 'My changes'

Repeating this step until the task is complete. Then, to get the changes back into the master branch. Switch to it

git checkout master

And pull the changes from the branch

git pull . my_branch

Easy. No need to remember revision numbers where you branched, or which changed have already been merged. You can of course switch back to the branch and continue work with

git checkout my_branch

this “edit, commit, pull” cycle can continue until the task is complete. Then, once you’re satisfied you can delete the branch with

git branch -d my_branch

It’s still in the history of course, but no need to keep old branches around.

Hope that makes things clear to anyone else who was confused as I was by some of the overly complicated explanation of branching in git.

Since I was first introduced to CouchDB late last year when Jan Lehnardt discussed it on the PHP Abstract Podcast my interest was piqued. I have since read as much as I can about it, which doesn’t actually amount to a great deal unfortunately. However, I think the idea has merit as an alternative to relational databases in various scenarios.

I have been using memcached to store aggregated objects and it often seems pointless to break them into disparate parts to fit into a relational schema. While I realise CouchDB is not an object cache, being able to store data "as is", in a form (JSON) that is directly malleable by many languages makes a lot of sense.

The "views", used to retrieve data, select the documents to return by passing them through user defined JavaScript filter functions, instead of querying using SQL as in most relational databases; providing near infinite flexibility for data retrieval.

The major concern that I haven’t seen adequately addressed is performance, especially given larger datasets. With the unstructured nature of the data and the flexibility of the view functions, it seems performance could be a challenge. Though given Erlang’s ground up concurrency and some of the algorithmic genius they have apparently borrowed from Google’s MapReduce — datasets don’t get much larger than that — I might yet be proved wrong. I hope I am.