post-receive hook and branches

Installing a post-receive hook in a git repository can be used to automate a lot
of things, i.e. initiate deployment, precompile a static page, or similar. Using
a hook is quite easy, simply create an executable file named like the hook inside
the hooks folder. So here we go

Init a bare repository

$ mkdir ~/test.git && cd ~/test.git
$ git init --bare

Init a repository

$ mkdir ~/test && cd ~/test
$ git init
$ git remote add origin ~/test.git

Create a hook

$ touch ~/test.git/hooks/post-receive
$ echo 'echo "I am a post receive hook"' >> ~/test.git/hooks/post-receive
$ chmod +x ~/test.git/hook/post-recive

Pushing to the repository means the hook is executed

$ cd ~/test
$ touch foo.txt
$ git add foo.txt
$ git commit -m 'foo'
$ git push origin master
...
remote: I am a post receive hook
...

To do more fun stuff it is sometimes important to know which branch got pushed,
to do this a couple of things are passed to the hook via stdin, so

https://gist.github.com/sideshowcoder/5751530.js

to detect the branch simply check against the $ref.

Happy hooking ;)

Simple git work flow

Simple git work flow

The concept of having multiple branches of code and merge them when needed is
a complicated concept to many people. When SVN was first introduced it started
with the premise to be a “CVS done right”. This means cheap branches, as well as
what is supposed to be easy merging. Actually SVN is a great hassle to use especially
when working with branches, which is why a lot of developers are actually
not really fund of branching and merging all the time. But git is different,
really, honestly… well at least to me ;)!

After working with git for some time now I got in the habit of a pretty basic
usage pattern which works quite well for me, so let me introduce you to it. Whenever I
want to work on a new feature I first branch of the current master to have my
own little sandbox to work and explore in.


$git checkout -b feature_XYZ

Now I got an unchanging environment, in which I can work and there is no one
else changing stuff except me (or maybe a small team). Commits only happen to
this branch.

After the feature is done the code needs to be merged in the master again.
Since the master probably changed during the implementation, I first rebase the
feature branch so I can actually do the merge inside the branch and don’t break
the master. So first pull the newest master and than rebase.


$git pull
$git rebase master

If there is a conflict I resolve it and create a commit describing the merge and
continue the rebase


$git add CONFLICTINGFILE
$git commit -m
$git rebase --continue

After rebase is done I switch to the master and do a merge which should not have
any conflicts now


$git checkout master
$git merge feature_XYZ

Now the whole thing can be pushed, while the master was working all the time,
and therefore a real parallel work on multiple features is possible. This is
possibly not suitable for work in large teams but for me as a single developer
working in small teams most of the time it works amazingly well.

Introduction to Git and how to using it

Recently git gained a large userbase, and is quickly becoming the default standard for version managment. So for me it
was time to get a larger understanding of it besides just “using it like I think it works”. So to get up to speed
quickly I decided to search for some talks on it. So here my quick introduction worth watching.

GoogleTechTalk: Git

Great talk by Randal Schwartz about Git. Even though it’s not the newest it really is a great explanation of the concepts. Since embedding sadly is disabled check it out at youtube. Like with pretty much everything Randal does the talk is really worth it.

O’Reilly Webcast: Git in One Hour

For an introduction to actually using git the O’Reilly Webcast is a great resource

Cheat Sheet

Nice command overview

Git Tower

For those not really that familiar with the command line, or people like me who keep forgetting the command, Git tower is quite a nice app to use with Git.