Coder Legion - Recent posts tagged merging

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.

Rewinding Time in Git: Exploring Commits & Branching

Fri, 27 Jun 2025 07:07:54 +0000

In the last story, we created a new repository on GitHub and pushed our code to the main branch. In this one, let’s rewind a bit, I'll walk you through how to look back at your development history and test new features safely using Git.

By now, you’ve probably updated your project and pushed changes quite a few times. Every commit you've made is like a snapshot, a version of your project frozen in time.

But how do you go back and look at an old version, maybe just to check a single line of code?

Most people head to GitHub -> Commits tab. But you don’t need to leave the terminal for that. Here's how you can do it right from the command line.

See Your Project’s History

git log

This shows a list of commits made by you and your collaborators. Each commit is identified by a unique 40-character SHA-1 hash. This hash acts like a version ID.

A sample log entry looks like:

commit 7abd5964ad8ef67ac20f5c52eea34e0d3bebe110
Author: hiruthicShaSS <*Emails are not allowed*>
Date: Fri Jun 25 16:42:07 2021 +0530

    Opening articles in new tab and card title fixed

That’s a lot of info! Let’s trim it down.

Get Specific Commits

Want just the last few entries?

git log -3

Want logs after a specific date?

git log --after="2021-05-01"

Combine with --before to get a date range!

Want Less Detail? Use --oneline

git log --oneline

This condenses each commit into a single line:

7abd596 Opening articles in new tab and card title fixed

To include branch and tag info too:

git log --oneline --decorate

Or if you're just looking for a human-friendly summary:

git shortlog

Enter Branches

Every Git project starts with the default main branch. But you shouldn’t develop or test directly on it. That’s what branches are for.

Check your current branches:

git branch

Let’s create a new one for development:

git branch development

But wait, this doesn’t switch to the new branch yet. To move to it:

git checkout development

Or do both in one shot:

git checkout -b development

Honestly, this is what I always use .

Why Branching Matters

Each branch is an isolated version of your code. You can try out features, break stuff, go wild, and it won't affect your main branch. When you're done and happy with your changes, you can merge it back.

If it all goes south? Just delete the branch and start over from main (just kidding, we'll talk how to fix f*ckups in git later).

Working with Git branches is like owning the Eye of Agamotto, every time you mess up, you can just rewind time and try again. Cool, right?

Until then:

Learn Git. Get fit.

Stay Curious. Adios ✌️

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.