background preloader


Facebook Twitter

Why I Like Mercurial More Than Git. After working for over a year alternating between two projects, one that uses Git for its version control and another that uses Mercurial, I have finally achieved sufficient mastery of both toolchains that I now feel comfortable defending my judgment that Mercurial is the superior of the two systems.

Why I Like Mercurial More Than Git

I think Git has one glaring deficiency that makes it the inferior tool, and I hope to describe the required remedy in this weblog posting. The tools are very similar, and many of the distinguishing differences come down to a matter of taste in my opinion. Some may consider it a deal-breaker that Mercurial expects its extensions to be written in Python, whereas Git admits extensions written in just about any language you care to imagine, but the usual approach is to write them in a shell language. That's not a deal-breaker for me. Many other differences are either consequences of that fundamental distinction, or they are cosmetic in nature. Understanding the Git Workflow. If you don’t understand the motivation behind Git’s design, you’re in for a world of hurt.

Understanding the Git Workflow

With enough flags you can force Git to act the way you think it should instead of the way it wants to. But that’s like using a screwdriver like a hammer; it gets the job done, but it’s done poorly, takes longer, and damages the screwdriver. Consider how a common Git workflow falls apart. Create a branch off Master Work Merge it back to Master when done Most of the time this behaves as you expect because Master changed since you branched. Unfortunately, your feature branch contained checkpoint commits, frequent commits that back up your work but captures the code in an unstable state. So you add a new rule: “When you merge in your feature branch, use –no-ff to force a new commit.” Then one day you discover a critical bug in production, and you need to track down when it was introduced.

You narrow the bug to a single file. Rethinking Revision Control Revision control exists for two reasons. The Workflow. DVCSAnalysis - support - Analysis of Git and Mercurial - User support for Google Project Hosting. A successful Git branching model » In this post I present the development model that I’ve introduced for some of my projects (both at work and private) about a year ago, and which has turned out to be very successful.

A successful Git branching model »

I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management. It focuses around Git as the tool for the versioning of all of our source code. (By the way, if you’re interested in Git, our company GitPrime provides some awesome realtime data analytics on software engineering performance.)

Why git? For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. But with Git, these actions are extremely cheap and simple, and they are considered one of the core parts of your daily workflow, really.