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.