There’s a trend that’s like a runaway train in Open Source development : the Git distributed version control system (DVCS).

It is the kind of software that makes you scratch your head, and even before starting to work with it. I mean, it can lead you in places you never thought existed (Headless, literally ! even funnier, it has valid though uncommon uses) teeming with tentacle-bearing monsters. When you look up how to do something, everyone seems to be doing it differently, and even code luminaries like Lars Vogel, of EGit fame – that is, git on Eclipse – say some things are too complicated (only to get drown in an outspurt of alternative methods by git fans). Git fans, now – listen to them and you’ll start believing that there is only One Single Worldwide Repository, and that git makes out of version control a game and an art, where masterpieces are elegant commit histories with bushy branches and diligent pruning.

And the apex : git’s actually done something no other DVCS ever did, that is making DVCS popular, and here I bring the praiseworthy Github as witness.

IMHO all that is precisely why it succeeds. Because though git is complex, complexity is inherent to DVCS principles such as peer-to-peer, so in order to succeed it had to target people who not only would be able to tackle such complexity but even thrive on it. And here I name you, fellow code geeks and hackers, eager to play the git game and share your achievements and your solutions and talk about them.

Anyway, you now won’t be suprised anymore to know that Git has a user manual, but no user guide. And while gitting in is easy, I’ve been bitten as soon as I’ve encountered merge conflicts. So here I partake in the great git fest with my Easy Git Merge Guide:

Easy Git Merge Guide

Conflicting changes can be solved by doing a merge and committing it. However, there are often better alternatives, especially when it gets complex :

• if you’ve not yet committed, put uncommitted work temporarily aside, and “pop” it back once (auto)merge is done : stash
• if you’ve committed but not yet pushed, delete your last commit(s): reset
• if you’ve already pushed, add another commit that reverts changes back : revert

(taken from the EasySOA Git Quickstart – those who get why Basics don’t talk about clone or pull get a cookie)

… do you happen to do otherwise ?!