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
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 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.