In October 2008, a developer at GitHub named Tom Preston-Werner wrote a blog post describing a workflow called "GitHub Flow." The core of the idea was simple: the main branch always contains deployable code, and every new piece of work - no matter how small - gets its own branch. When the work is finished and reviewed, it merges back into main. The post became one of the most influential documents in software development practice of the last two decades, not because it introduced something technically novel, but because it articulated a way of working that Git's branching model made suddenly easy. Git branches are cheap. Creating one takes less than a millisecond. Switching between them is instantaneous. This is not an accident of implementation - it is a direct consequence of how Git stores data. ### What a Branch Actually Is In most people's mental model, a branch is a copy of the code. A separate directory, maybe, with all the files duplicated. That intuition is wrong, and the wrong intuition leads to unnecessary fear of branching. In Git, a branch is a pointer. A single, lightweight pointer to a specific commit. That is it. When you create a new branch, Git creates a new pointer that currently points to the same commit as the branch you are on. No files are copied. No directories are created. Just a pointer. As you make commits on the new branch, that pointer moves forward with each new snapshot. The original branch pointer stays where it was. The two branches diverge. But until you make that first new commit, they are pointing at the exact same history. Git also maintains a special pointer called HEAD, which simply tracks which branch you are currently on. When you switch branches, HEAD moves. Your working directory updates to reflect the snapshot that the new branch points to. **Key Point:** A Git branch is a pointer, not a copy. Creating a branch is free in time and space. There is no technical reason to avoid branching, only workflow reasons to use it deliberately. ### Creating and Switching Branches `git branch feature-user-profiles` creates a new branch pointing at your current commit. You are not on it yet - you are still on whatever branch you were on. `git checkout feature-user-profiles` switches you to that branch. HEAD now points to it. Your working directory reflects the files at that point in history. The modern shorthand combines both steps: `git switch -c feature-user-profiles` creates and switches in one command. (Older tutorials use `git checkout -b`, which does the same thing - both work.) From this point, every commit you make goes onto `feature-user-profiles`. The main branch stays untouched, still pointing at the last known-good snapshot. ### Merging Work Back Together When your feature is finished and tested, you want to bring those changes back into main. This is merging. Switch to the branch you want to merge into: `git checkout main`. Then: `git merge feature-user-profiles`. If main has not changed since you branched off, Git performs what it calls a fast-forward merge. Since your branch is simply ahead of main in a straight line, Git just moves the main pointer forward to match your feature branch. No new commit is created. The history stays linear. If main has received other commits while you were working on your feature - which is common on teams with multiple people - the two branches have diverged. Git finds the common ancestor commit, compares both branches' changes against it, and creates a new merge commit that ties the two histories together. That merge commit has two parents: the last commit on main and the last commit on your feature branch. ### When Git Cannot Decide: Merge Conflicts Occasionally, two branches make different changes to the same line of the same file. Git cannot know which version is correct - that is a human judgment. So it stops and asks you. A conflict looks like this inside the affected file: ``` <<<<<<< HEAD const timeout = 3000; ======= const timeout = 5000; >>>>>>> feature-user-profiles ``` Everything between `<<<<<<< HEAD` and `=======` is what main had. Everything between `=======` and `>>>>>>>` is what your feature branch had. Your job is to edit the file to the version that is correct - maybe one, maybe the other, maybe a hybrid - and remove the conflict markers entirely. Once you have resolved all conflicts, stage the resolved files with `git add` and complete the merge with `git commit`. Git will suggest a merge commit message; you can keep it or customize it. Conflicts are not failures. They are Git telling you that two people made decisions about the same piece of code and a human needs to reconcile them. On a healthy team with small, focused branches, conflicts are rare and easy to resolve.

Your Code Has a Time Machine: Git from the Ground Up