Git Workflow & Branching – An Aftermath

Git is such a masterpiece tool that programmers use for collaboration work with others. Use it carefully and it will help you very much. Careful you not will trigger a wildfire in the codes. In our implementation of git workflow and branching, we have faced some problems. Actually, I don’t know what to write, so let’s just pretend this is a serious problem.

btw, Git 2.13.0 just released by our Savior, Torvalds

My name is Linus Torvalds, and I am your god. — Linus Torvalds

In the beginning of last sprint (sprint 2), our team decided to use rebase to merge branches. The main reason why we want to use branch is to maintain nice code history in our repository. We have tried it for some time, but turns out it is one of the dark side of Git. We encounter some problems when using git rebase, most of the problems are related to pre-existing inconsistency in our repository.

Before deciding to use rebase, we have used merge in our develop branch. Switching to rebase means deleting our repo history from the very first commits. Plus, rebasing means squashing merged commits, deleting the very important history even more. We later decided to only use rebase in feature branches.

Never, ever forget history. — Soekarno

Unfortunately, other problem appeared: we had a decision to organize our branch in such way like develop -> featureX_master -> featureX-Y. Organizing the branch in that form makes us need to rebase featureX_master to rebase featureX-Y and of course it’s impossible to do. Rebase will not work if merged (or rebased) branch is kept after merge is done. Doing so, the commits will diverge with local commits that programmers have and conflicts will appear accross the codes. In our implementation of branches, the featureX_master is kept, so it will always diverge with local commit and cannot be merged easily.

Finally we must say goodbye to rebase and choose merge again, because merge is hazzle-free to use.

With these problems that we faced in implementing rebase, I think git rebase is more suitable for a company that don’t-give-a-f**k to git history. When doing merge request to develop, use rebase instead and squash the commit. Yes, it will delete the history, but who wants a messy history? A clean and neat history will do.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s