Understanding the Git Workflow

If you don’t understand the motivation behind Git’s design, you’re in for a world of hurt. 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

A successful Git branching model » nvie.com Note of reflection (March 5, 2020)This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.This is not the class of software that I had in mind when I wrote the blog post 10 years ago. Why git? For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. The main branches ¶ develop

The Law of Leaky Abstractions by Joel Spolsky Monday, November 11, 2002 There's a key piece of magic in the engineering of the Internet which you rely on every single day. It happens in the TCP protocol, one of the fundamental building blocks of the Internet. TCP is a way to transmit data that is reliable. We use TCP for many things like fetching web pages and sending email. By comparison, there is another method of transmitting data called IP which is unreliable. Here's the magic part: TCP is built on top of IP. To illustrate why this is magic, consider the following morally equivalent, though somewhat ludicrous, scenario from the real world. Imagine that we had a way of sending actors from Broadway to Hollywood that involved putting them in cars and driving them across the country. That is, approximately, the magic of TCP. Back to TCP. This is what I call a leaky abstraction. Abstractions fail. During my first Microsoft internship, I wrote string libraries to run on the Macintosh. Next: Lord Palmerston on Programming