Coder Legion - Recent posts tagged branching

Branching Strategies

Wed, 08 Jul 2026 09:00:00 +0000

Tony Kelly hosts our latest episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.

Your branching strategy can support Continuous Delivery, or make it an impossible goal. Teams should assess the impact of how they branch on their ability to deliver software at all times, and that means there are some branching techniques that make software delivery more like walking in the dark through a field of rakes.

Listen now to discover:

The best branching strategies
The worst possible branching strategy
How branching fits into Continuous Delivery
Confessions from our worst merges

Learn Git fast as if your job depends on it

Mon, 16 Feb 2026 19:40:07 +0000

TL;DR

In this post, with a grain of humor, I'm going to show you the minimum number of Git commands that you need to learn in order to start being productive and get that code from your machine to the company Git server. Also, I'll cover a bit of theory and Git installation as well.

Disclaimer

⚠️ Nobody in this story, and no outfit or corporation, thank God, is based upon an actual person or outfit in the real world. But I can tell you this; as my journey through the software jungle progressed, I came to realize that, by comparison with the reality, my story was as tame as a holiday postcard. ~ John le Carré

Setting the stage

So, let's set a scene; it's your first day as a junior developer straight out of college. You get to work, greet your superior that's supposed to be responsible for you, and since he's too busy with putting down some fire that just popped up, he, conversely, while you're trying to keep up walking aside him tells you something like:

I've set the Git access for you to my website project.

You have a ticket in our project management tool assigned to you. No worries, it's just some simple stuff that needs to be changed.

Just check the email details, and you can start immediately.

I'm aware that you may not be familiar with Git. I'm not trying to be an asshole, but just deal with it, learn it, OK? Don't they, like, teach you kids nothing in school these days?

Ah, I gotta run.

Oh, and one more thing, look up branching and do not EVER, and I repeat - EVER, commit to master; do a PR instead! Good luck and see ya later!

OK. You sit down at your cubicle, open up your email client, log in, and there you see the email (without the subject line, of course) with the contents:

Here's a link to the Git repo on Github.

Good luck,
Mr. Superior

Reality sets in

⚠️ This, in and of itself is a poor onboarding if you ask me, but I personally have seen it way too many times, so here are the things you need to do to get productive fast and learn the ropes as fast as you can.

So now you're, in lack of better words, screwed (you know the exact word, but we're not supposed to be using profanity here, ae?).

You're lost. You heard about Git before, but you never used it. Now you're kicking yourself for not learning it properly yourself. But, it is what it is, and since you're really determined to make it in this 'programming' world, you're ready to do what it takes.

I would question the fact that if you are 'so into it', how come you haven't learned it yet, but as Mr. Superior said, I'm not trying to be an asshole

Therefore, buckle up young padawan, you're in for a ride!

What is this Git thing?

First, let me start off with a few problems:

Say you're writing a seminar and you make some changes, save them, go out of the text editor, come back, and you want to see all of your changes that you did last in the file. Or, for example, you want to undo some changes that you did last night (writing a seminar after returning from a party is a noble act, but not a very smart one!).
While writing this seminar you create several versions of the same file and you don't even know what's changed in which version; you would really love to know what was, for example, changed in this current version based on the, say, a version from a few days ago.
You're working on a group project and someone deletes your changes 'by accident'.

VCS (Version Control Systems) tends to solve these problems. And, let me start off by saying that no, you don't need to use VCS only for writing code (thus the seminar example). You can use it for any textual project. One of VCS solutions is Git. One other popular VCS, that's still used to some extent today is Subversion. You can see a detailed list of Version Control Systems here.

Git was made by the ever so slightly genius Linus Torvalds, the father of Linux:

Git is a distributed version control system (VCS).

Version control means that you use it to store versions of your documents. True, it seems it's very popular among developers, but designers and other people (that are a bit more tech savvy) also use it to track versions of their files.

This whole distributed part is one of the things that makes it different from other VCS. Rather than have only one single place for the full version history of the software, as is common in once-popular VCS like CVS or Subversion, in Git every developer's working copy is also a repository that can contain the full history of all changes.

OK, but what is Github?

Something like Dropbox, but customized for Git.

Github is a hosting service for Git projects, with some additional batteries included that we're not going to get into at this point, as you're short on time. Think of it as a place where you store your Git 'stuff'.

Installing Git

To install Git, go to the official website and download the executable for your machine. I'm not going into the installation details as they're really just a bunch of Next, Next, Next, yes to malware, Finish set of steps. I'm kidding about the malware OFC.

To make sure your installation was successful, run the following command in your Terminal/Command prompt:

git --version

You should get something like:

git version 2.10.1

Fetching the repo

OK, so let's finally get some action. In your email, you received an URL to the Git repository. It was this: https://github.com/Hitman666/MrSupervisorWebsite. You click the link, and you see something like this:

Click the Clone or download button, make sure you see the Use SSH in the top right corner of a popup and copy the link.

To get this repository to your computer, you have to execute the following command in your Terminal/Command prompt (I'll use Terminal in the rest of the post):

git clone https://github.com/Hitman666/MrSupervisorWebsite.git

The output of the command should look something like this:

Cloning into 'MrSupervisorWebsite'...
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 7 (delta 0), reused 7 (delta 0), pack-reused 0
Receiving objects: 100% (7/7), done.

Checking out the code

Now, go into the newly created MrSupervisorWebsite folder and open it in your editor.

You should see three files: index.htmnl, style.css, and README.md.

You quickly go and click to open the README.md file, but all you see is this:

# MrSupervisorWebsite

Hmm, so, no help there.

You open up the index.html file and you see:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>MrSupervisorWebsite</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1 class="title">Welcome to MrSupervisorWebsite!</h1>
</body>
</html>

OK, finally something that you're familiar with! You also open up the style.css file, and you see:

.title {
    color: blue;
}

Next, you take a look at the ticket assigned to you in the project management tool that Mr.Superior mentioned, and it looks something like:

You take a deep breath, finally something that you know how to handle!

You're a bit taken aback by the 'manly color', so you go and ask Google:

You pick the 4872A2, and you're happy. You think to yourself: OK, now I just need to change this color in the style.css file, somehow add this to this Git thing and 'publish' it.

You're right, but not so fast! You remember that note from Mr.Supervisor that you shouldn't commit to master, EVER?

Creating a new branch

So, what is this master anyway? You go online, and you find that:

Git has branches, and its main one is called master. You can create as many of them as you want, based on any other existing one.

Also, you read a bit about the PR, and you learn that:

PR is short for Pull Request. Pull requests let you tell others about changes you've pushed to a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository.

So, this is smart, right? You can add your code to the Git repo without breaking any existing stuff on the master branch, and through this PR you can then ask a more experienced developer to do a CR (code review) on your PR and accept it or not.

You're smart; you see the huge benefit of this vs. just committing something to master and potentially breaking something in production.

Now, to circle back a bit and explain how could it be that you would break something!? Well, there's a thing called CI (Continuous Integration) and CD (Continuous Deployment), and you can read more about it, but in essence, it's this:

Every time someone pushes a new commit to master branch, a whole set of deploy scripts are being triggered, and essentially the new code that's pushed is going to appear in production.

What this means is that if you change that color and you commit it to master (you'll learn in a minute how to actually do this commit action), it will 'automagically' appear in the production on the website.

⚠️ Of course, the premise is that the service is set like that in the first place.

So, you get the point and value of additional branches, and you create a new branch by executing the following command in your Terminal:

git checkout -b poppingTitle

The upper command is a shortcut for two commands:

git branch poppingTitle
git checkout poppingTitle

The first one creates a new branch called poppingTitle from the current branch that you're on (in our case that's master). The second one 'checks it out'. Meaning, it places you on that branch.

Adding some code

Now you're finally ready to add some code!

Open up the style.css file, change the color, and save the file. It should look like this now:

.title {
    color: #4872A2;
}

One useful command that you'll use a lot is git status, which will you tell you the status of your git project. If you execute that in your Terminal you will see that the style.css file was modified:

On branch poppingTitle
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   style.css

no changes added to commit (use "git add" and/or "git commit -a")

As you can see, in the instructions from the output, these changes are not yet added to the commit. To do that, execute the command git add style.css. Of course, if you were to have multiple files you would not have to list each and every one of them, you would just use git add . command.

If you run the git status command again, you'll see that we have changes that are ready to be committed:

On branch poppingTitle
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   style.css

Committing code

To commit (one could use words like save or apply here for better clarity) the added changes to your local repository, just run:

git commit -m "Changed the title color"

Of course, the commit message can be anything, but please do yourself a favor and write meaningful commit messages.

If you run the git status command again, you'll see that we have a clean repository:

On branch poppingTitle
nothing to commit, working tree clean

Pushing to a remote repository

So, great, at this point you have the change locally in your repository, but you'd like to get this back to Github (the so-called remote repository, or origin as it's usually referred to).

For that you have to execute the following command:

git push origin poppingTitle

You should get an output similar to this:

Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:Hitman666/MrSupervisorWebsite.git
 * [new branch]      poppingTitle -> poppingTitle

Doing a PR

If you check Github now, you'll see that we've pushed this new branch:

Now, click on the Compare & pull request button.

Here you can add some comment summarizing your pull request:

Finally, click the Create pull request button.

And now (if we're playing by the book) someone else from your team would come and review your code. At this point, you could let someone know about this via your Project Management Tool (JIRA, Trello, Leankit, Kanbanflow, etc...) by putting this task/card in the appropriate column.

Your PR is accepted

When the pull request is approved (you get a notification from Github when someone approves or rejects it), you as the author go back to Github and just click on the Merge pull request button, and that's it:

Finally, click the Delete branch button as it's a good practice to not keep the merged branches in the remote repo:

You get to live another day

Your merge to master goes well, it's auto-deployed, you check the website and all is cool. You update the ticket in your ticketing system by placing it in the 'Deployed' column (or some similarly named column).

It's 17:12, you close your laptop and cheerfully go home to learn more about this awesome Git thingy.

Git Deep Dive: Mastering rerere

Thu, 13 Nov 2025 01:38:15 +0000

No, It's Not a Typo: Let's Talk About git rerere (Reuse Recorded Resolution)

git rerere helps Git remember how you resolved a conflict previously, and automatically reuses that resolution when the same conflict occurs again. This can be a huge time-saver with recurring merge conflicts.

How to enabled it

Globally:

git config --global rerere.enabled true

Per project:

git config rerere.enabled true

Check status:

git config --get rerere.enabled

Example

I'm updating hello.txt on main and feature/earth branch.

Hello!

On main branch:

Hello World!

On feature/earth branch:

Hello Earth!

Now, if we try to merge feature/earth into main, we’ll get a conflict:

git checkout main
git merge feature/earth

Conflict:

<<<<<<< HEAD
Hello World!
=======
Hello Earth!
>>>>>>> feature/earth

We edit the file to:

Hello Universe!

Then stage and commit:

git add hello.txt
git commit

Git will record the resolution:

Recorded resolution for 'hello.txt'.
[main 7fd7eda] Merge branch 'feature/earth'

Next time Git encounters the same conflict, it will automatically reuse the previous resolution:

git merge feature/earth

You got:

Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt
Resolved 'hello.txt' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.

Useful commands

# Manually trigger rerere
git rerere

# Forget a recored resolution
git rerere forget <file>

# Check the rerere cache
ls .git/rr-cache/
cat .git/rr-cache/<conflict-id>/preimage

If you don’t want Git to auto-resolve using rerere, you can reset the file:

git checkout --conflict=merge <file>

Advanced

When Git detects a conflict during a merge or rebase, it generates a hash key based on the conflicting content — this becomes the conflict-id.

Git then stores:

The preimage (conflicted content)
The postimage (your resolved version)

These are saved under .git/rr-cache/.

File Structure:

.git/
└── rr-cache/
    ├── <conflict-id>/
    │   ├── preimage      # The file before conflict resolution
    │   ├── postimage     # The file after conflict resolution
    │   └── thisimage     # Temporary file used during auto-resolution

Important Notes

The conflict-id is not a Git object, even though it looks like one.
It’s stored locally only — it won’t be pushed to the remote.
If you delete .git/rr-cache, the resolution is gone forever.

Summary

git rerere is a powerful but often overlooked tools. It can save you a lot of time when dealing with recurring merge conflicts.

Mastering Collaborative Coding: A Deep Dive into Git Branching and Merging for Teams

Tue, 24 Jun 2025 15:26:00 +0000

Let's imagine a scenario without Git first to see the problem, and then we'll see how branching and merging provide the perfect solution.

The Problem: The "Single Shared Document" Nightmare

Imagine you and a colleague (let's call them Coder A and Coder B) need to edit the same file, app.js.

Coder A is adding a new user login feature.
Coder B is adding a new search bar feature.

Without a system like Git, they might:

Both download app.js to their computers.
Coder A works for three hours and adds 50 lines of code for the login feature.
Coder B works for three hours and adds 40 lines of code for the search bar, in some of the same places.
Coder A uploads their new version of app.js to the shared server first. The server now has the login feature.
A minute later, Coder B uploads their new version. This completely overwrites Coder A's work. The login feature is gone, and only the search bar exists.

This is a classic "last write wins" problem. It leads to lost work, frustration, and a need for constant communication like, "Hey, don't touch app.js today, I'm working on it!"—which completely kills productivity.

The Solution: Git's Branching and Merging Workflow

Git solves this with an elegant workflow that allows for safe, parallel development.

Here’s how it helps your two coders working on the same file:

1. The Stable Foundation: The `main` Branch

Think of the main branch (sometimes called master) as the official, stable, working version of your project. This is your "source of truth." No one works directly on main.

(main branch) A---B---C  (C is the latest stable version)

2. Branching: Creating Isolated Sandboxes

When Coder A and Coder B start their tasks, they each create a branch. A branch is essentially a personal copy of the project at a specific point in time.

Coder A creates a login-feature branch.
Coder B creates a search-bar branch.

                  (login-feature branch)
                 /
(main branch) A---B---C
                 \
                  (search-bar branch)

Now, they are working in complete isolation. Any changes Coder A makes to app.js on their login-feature branch are invisible to Coder B, and vice-versa. They can both edit the same file without fear of overwriting each other's work.

3. Working in Parallel

Coder A adds commits to their branch, and Coder B adds commits to theirs. The project history now looks like this:

                  D---E  (Coder A's login work)
                 /
(main branch) A---B---C
                 \
                  F---G  (Coder B's search bar work)

The main branch remains untouched and stable. If the CEO needs a demo, you can always rely on the code in main.

4. Merging: Combining the Features

This is the magic step. When a feature is complete, it gets merged back into main.

Scenario 1: Coder A finishes first.

Coder A opens a Pull Request (or Merge Request), which is a formal way of saying, "I'm done with my work on the login-feature branch. Can someone please review it and approve merging it into main?"

The team reviews the code, and it's approved. The merge happens.

                  D---E
                 /     \
(main branch) A---B---C-------H  (H is the new "merge commit")
                 \
                  F---G

The main branch now contains the original code plus Coder A's login feature.

Scenario 2: Coder B now wants to merge.

Coder B's search-bar branch is now "behind" the main branch. Before they can merge, they must first update their branch with the latest changes from main.

# While on the search-bar branch
git pull origin main

Git will now try to automatically merge the changes from main (which include the login feature) into Coder B's branch.

The Easy Case (No Conflict): If Coder A and Coder B worked on completely different parts of app.js (e.g., A worked at the top, B worked at the bottom), Git will seamlessly merge the changes. No manual work needed.
The Harder Case (Merge Conflict): If both coders edited the exact same lines in app.js, Git will pause and say, "I don't know which version to keep. You, the human, need to decide." This is a merge conflict. It will mark the file like this:
```
<<<<<<< HEAD
// Coder B's search bar code that conflicts
=======
// Coder A's login code that conflicts
>>>>>>> main
```
Coder B then simply edits the file to resolve the conflict—they might keep their code, keep the other code, or combine them. Once resolved, they commit the file and can finish their merge. The key is that the conflict is handled by one developer on their own branch, not on the main branch where it could break things for everyone.

Summary of How It Helps:

Isolation: Developers can work on new, experimental, or even broken code without affecting the stable main codebase.
Parallel Development: Multiple developers can work on the same file at the same time, dramatically increasing team velocity.
Structured Integration: Merging (and Pull Requests) provides a formal process for code review and quality control before new code is added to the main project.
Conflict Management: Git provides a clear and robust system for identifying and resolving conflicts when they inevitably occur, ensuring no work is accidentally lost.

In short, branching and merging transform a chaotic, error-prone process into a safe, organized, and highly efficient workflow, which is the foundation of modern collaborative software development.