DEV Community: Anderson Chinedum

I Deliberately Broke a Git Merge to See What Happens Under the Hood

Anderson Chinedum — Fri, 30 Oct 2026 14:34:42 +0000

I Wanted Git to Fail. And It Did.

I know, that sounds a little crazy. Most developers spend their time trying to avoid errors, and here I was deliberately trying to create one.

But I had a reason.

While experimenting with GitFlow, I became curious about what actually happens when two branches introduce conflicting changes. I've seen merge conflicts before, but I wanted to understand what Git was doing rather than just follow instructions to get rid of the error.

So I decided to put it to the test.

I created conflicting changes on two branches, attempted to merge them, and watched Git respond:

Auto-merging conflict.txt
CONFLICT (add/add): Merge conflict in conflict.txt
Automatic merge failed; fix conflicts and then commit the result.

And there it was. Git refused to complete the merge.

Exactly what I wanted.

But here's where things got interesting. Creating the conflict was relatively easy. Understanding why Git stopped, deciding how to resolve it, and making sure my repository ended up in the right state was a different story.

This experiment took me through GitFlow branching, GitHub pull requests, squash merges, conflict resolution, and finally synchronizing the branches.

Let me walk you through what happened.

Setting Up the Experiment with GitFlow

Before I could deliberately break a merge, I needed a proper branching workflow to experiment with.

I created a repository called gitflow-trunk-strategies and used a GitFlow-style approach with three branches:

main — the primary branch representing release-ready work.
develop — the integration branch where feature changes come together.
feature/user-login — a temporary branch for developing an individual feature.

After initializing the repository and creating the first commit, I set up the development and feature branches:

git checkout -b develop
git checkout -b feature/user-login

Nothing complicated yet.

However, one thing worth remembering is that Git branches aren't separate copies of a project. They're references to commits.

As new commits are introduced, those references move forward, and the branches can develop different histories.

That's what makes branching useful, but it's also what creates interesting situations when you try to combine changes later.

Creating the feature/user-login branch.

Creating a Feature

To make the experiment practical, I created a simple placeholder for a user-login feature:

echo '# Login feature' > login.md

git add login.md
git commit -m "feat: scaffold user login"

This wasn't a complete authentication system. I only needed a real change that could be committed, pushed, and merged.

The feature branch was now ahead of develop by one commit.

Committing the login feature and inspecting the Git history.

A Quick Note on GitFlow vs. Trunk-Based Development

GitFlow typically uses a long-lived develop branch alongside main, with feature branches created for individual changes.

Trunk-based development, on the other hand, encourages developers to integrate small changes into the mainline frequently.

Both approaches have their uses.

The interesting part is that neither branching strategy magically prevents merge conflicts. Git still has to figure out how to combine changes when branches diverge.

And sometimes, it simply can't make that decision for you.

Getting the Feature into GitHub

With the feature committed locally, I wanted to take it through a proper pull request workflow.

I already had my GitHub repository connected to the local project, with main and develop pushed to the remote.

I used GitHub CLI (gh) to manage the process from my terminal.

First, I pushed the feature branch:

git push -u origin feature/user-login

Then I opened a pull request:

gh pr create \
  --base develop \
  --head feature/user-login \
  --title "feat: user login scaffold" \
  --body "Adds the login module skeleton."

GitHub created Pull Request #1.

The pull request proposing changes from feature/user-login into develop.

One detail I paid attention to was the target branch.

I used --base develop because I wanted the feature to enter the integration branch first, rather than merge directly into main.

Why I Used a Squash Merge

After checking the pull request, I completed it using:

gh pr merge feature/user-login --squash --delete-branch

A squash merge takes the changes introduced by the feature branch and records them as a new commit on the target branch.

For example, if a feature branch contains several intermediate commits for fixes and adjustments, squashing can combine those changes into one integration commit.

My feature only had one commit, but the exercise still demonstrated the workflow.

The pull request was merged successfully, and the temporary feature branch was deleted.

The feature successfully squash-merged into develop.

At this point, the feature existed on develop.

But main was still behind.

That wasn't an error. It was simply a consequence of the branching workflow. Merging into develop doesn't automatically update every other branch.

This distinction would become useful later in the experiment.

For now, though, I had something else in mind.

It was time to break a merge.

Time to Break Something: Creating the Merge Conflict

Here's where I stopped following the normal feature workflow and started experimenting.

I wanted Git to encounter two different versions of the same file and refuse to merge them automatically.

The plan was simple:

Create a file on main.
Create a different version of that file independently on develop.
Attempt to merge main into develop.

Creating the First Version on `main`

I switched to main:

git checkout main

Then created a file called conflict.txt:

echo 'main line' > conflict.txt

git add conflict.txt
git commit -m "main: add line"

The file contained:

main line

Creating a Different Version on `develop`

Next, I switched to develop:

git checkout develop

I created another file with the exact same name, but different content:

echo 'develop line' > conflict.txt

git add conflict.txt
git commit -m "develop: add line"

This version contained:

develop line

So now I had two branches that had independently added conflict.txt.

Same filename. Different content.

And both changes were already committed.

Attempting the Merge

While on develop, I ran:

git merge main

Git responded:

CONFLICT (add/add): Merge conflict in conflict.txt
Automatic merge failed; fix conflicts and then commit the result.

There it was again.

The merge stopped because Git couldn't automatically reconcile the two different versions of the file.

This particular situation is called an add/add conflict because both branches independently added the same file path.

And no, I hadn't damaged my repository.

Git was actually protecting the merge from proceeding with an ambiguous result.

Git detecting an add/add merge conflict in conflict.txt.

Now the question became: what exactly was Git struggling to reconcile?

What Was Actually Happening Under the Hood?

This was the part I was particularly interested in.

Git doesn't simply compare two files and pick the one with the latest timestamp.

For a typical three-way merge, Git considers three versions of the project:

The merge base: The common ancestor shared by the two branches.
Ours: The version from the current branch, develop.
Theirs: The version coming from main.

The common ancestor helps Git determine how each branch changed.

In my case, conflict.txt didn't exist in that common ancestor.

Both branches independently introduced the file, and their contents were different.

That's why Git reported an add/add conflict.

Understanding the Conflict Markers

When I inspected conflict.txt, Git had inserted markers similar to these:

<<<<<<< HEAD
develop line
=======
main line
>>>>>>> main

Let's break that down.

<<<<<<< HEAD

This marks the beginning of the current branch's version. Since I was on develop, that was the content Git considered "ours."

=======

This separates the conflicting versions.

>>>>>>> main

This marks the end of the incoming version from main.

Git was essentially saying:

"I found two competing versions of this file. I can show you both, but I need you to decide what the final result should be."

And that's exactly what merge conflict resolution is about.

There's More Going On Than Just Conflict Markers

Git also tracks unresolved versions through its index.

During an unresolved merge, the index can contain separate entries for the conflicting sides.

For an add/add conflict like mine, the relevant entries are typically:

Stage 2: The version from the current branch.
Stage 3: The version from the incoming branch.

There is no stage-1 version for that file because it didn't exist in the merge base.

One way to inspect those entries while a conflict is still unresolved is:

git ls-files -u

I didn't use this command during the original lab, but it's a useful way to explore the underlying conflict state in a future experiment.

The conflict markers were simply the visible part of a more structured process.

Git had the competing versions available. What it didn't have was enough information to choose the correct result automatically.

That's where I had to step in.

Fixing the Merge Without Losing the Changes

At first, I thought resolving the conflict meant removing the markers and keeping both versions.

But I wanted to understand whether that was actually how conflicts should be handled.

Turns out, there's an important distinction.

Removing conflict markers doesn't automatically mean you've resolved the underlying problem correctly.

Imagine two developers changing the same configuration setting.

One version might specify a database connection to one environment, while another points somewhere else.

Keeping both settings could introduce invalid configuration or unexpected behavior.

So the correct resolution depends on what the code is supposed to do.

In my experiment, the file contained nothing more than two demonstration lines. Both could safely coexist.

I edited conflict.txt and kept:

develop line
main line

I saved the file, then returned to Git Bash.

Telling Git the Conflict Was Resolved

I staged the corrected file:

git add conflict.txt

Then checked the repository:

git status

At this point, Git could recognize that the conflict had been resolved, but the merge itself was still waiting to be completed.

This was another useful lesson.

git add marks the resolved content as ready. It doesn't finish the merge commit.

To complete the process, I ran:

git commit -m "merge: resolve conflict between main and develop"

And just like that, the merge was completed.

The successful merge commit after resolving the conflicting file.

What Changed in the Git History?

Unlike the earlier squash merge, this operation produced a regular merge commit.

A normal commit usually has one parent, while a merge commit typically has two.

Those two parent references allow Git to record how the previously separate histories were connected.

I could inspect that relationship using:

git log --oneline --graph --decorate --all

This is one reason I find Git's history commands so useful.

A command reporting success is good.

Being able to inspect the resulting commit history is even better.

The conflict was resolved. But I still had one final task before calling the experiment complete.

The Merge Was Fixed. But Were My Branches Actually in Sync?

After resolving the conflict, I moved on to documenting the lab and publishing the final changes.

I created a README.md covering the branching strategies, pull request workflow, and important commands used during the experiment.

Then I committed it:

git add .

git commit -m "docs: add README for GitFlow vs Trunk branching lab"

Documenting the experiment and committing the README.

Next, I pushed the updated develop branch:

git push origin develop

But there was still something to address.

Remember that the login feature had been integrated into develop, while main had remained behind?

Even after resolving the conflict, the branches weren't automatically pointing to the same latest commit.

I needed to synchronize them.

Using a Fast-Forward Merge

I switched to main:

git checkout main

Then ran:

git merge --ff-only develop

The --ff-only option tells Git to merge only if it can advance the current branch without creating a new merge commit.

This works when the current branch's commit is already an ancestor of the target branch.

Because I had merged main into develop during the conflict-resolution exercise, Git could now fast-forward main to the latest commit on develop.

No additional merge commit was necessary.

Finally, I pushed main:

git push origin main

Verifying the Final State

I didn't want to stop at a successful push message.

I wanted to confirm that everything was actually where it should be.

So I ran:

git status
git branch -vv
git log --oneline --graph --decorate --all -12

Git reported a clean working tree:

nothing to commit, working tree clean

The final history showed main and develop, along with their corresponding remote-tracking references, pointing to the same latest commit.

The final Git history showing the synchronized branches.

That was the result I was looking for.

The conflict was gone, the changes were committed, the documentation was pushed, and the repository history was in the expected state.

Now I could actually say the experiment was finished.

Three Merge Strategies, Three Different Results

One thing this experiment helped me understand is that not every merge operation produces the same Git history.

I used three different integration approaches throughout the workflow.

Merge Strategy	What Happens	Why It Matters
Squash Merge	Combines the feature's changes into a new commit on the target branch	Keeps the integration history compact
Regular Merge Commit	Connects the histories of two branches with a merge commit	Preserves the relationship between the branches
Fast-Forward Merge	Advances a branch reference without creating a new merge commit	Useful when the current branch is an ancestor of the target

What's interesting is that all three approaches can successfully integrate changes, but the resulting history isn't identical.

With the feature branch, I used a squash merge.

When resolving the intentional conflict, I created a regular merge commit.

And when synchronizing main with develop, I used a fast-forward merge.

Seeing these operations in the same repository made the differences much easier to understand.

It also reinforced something important: the merge strategy you choose affects how future developers will read and understand the project's history.

That might not seem significant in a tiny lab repository.

But in a larger project with multiple contributors, meaningful commit history becomes much more valuable.

Final Thoughts: Breaking Things Can Teach You How They Work

I started this experiment with one goal: make Git refuse a merge.

And I succeeded.

But what I found interesting wasn't the error itself. It was everything I had to understand to get from that error back to a clean, synchronized repository.

A few lessons stood out to me:

A merge conflict doesn't mean your repository is broken. It means Git needs a decision it cannot make automatically.
Removing conflict markers isn't enough. You still need to make sure the resolved code behaves correctly.
A successful pull request doesn't mean every branch is up to date. You need to understand which branch received the changes.
Git history deserves attention. Commands like git status, git branch -vv, and git log --graph help verify the actual result.

And perhaps the biggest takeaway?

Getting a merge to succeed isn't the goal. Understanding what was merged, why it was merged, and whether the resulting history is correct matters much more.

This was a controlled experiment using simple files, not a complicated production application. But the underlying Git behavior is the same kind of behavior developers need to understand when collaborating on real projects.

I'll be taking that lesson into my future software engineering and DevOps work.

Explore the Repository

If you'd like to inspect the commits and branching workflow yourself, the completed repository is available on GitHub:

GitFlow vs. Trunk-Based Development Lab

I'm curious: have you ever resolved a Git merge conflict, only to discover that the resulting code or branch history wasn't what you expected?

I'd be interested to hear how you handled it.

I kept putting off learning SQL because I thought it would be complicated. Turns out, I just needed to start writing queries. Here's what changed my perspective. Give it a read!

Anderson Chinedum — Thu, 29 Oct 2026 07:20:39 +0000

Anderson Chinedum

Oct 29

SQL Was Always Just Database Stuff to Me. Then I Started Writing Queries

#sql #database #programming #devops

6 min read

SQL Was Always Just Database Stuff to Me. Then I Started Writing Queries

Anderson Chinedum — Thu, 29 Oct 2026 07:15:55 +0000

I'd been meaning to learn SQL for quite some time.

It wasn't that I had no interest in databases. I knew they were an important part of software development, but SQL was one of those things I kept pushing further down my learning list.

Whenever I thought about it, I pictured tables, rows, columns, and something similar to working with Excel. I understood that databases stored information, but I hadn't really explored how developers interacted with that information.

Eventually, I decided to stop postponing it.

I opened Codecademy's Introduction to SQL course and spent about an hour and fifteen minutes working through the Manipulation module.

What surprised me wasn't that SQL suddenly became effortless. It was how quickly the basic concepts started making sense once I began writing the statements myself.

The commands were descriptive, the examples were practical, and I could see how each operation affected the information stored in a table.

Here's what stood out to me.

SQL Made More Sense When I Stopped Thinking About It Like Excel

One of the first things I had to understand was what a relational database actually represents.

A relational database organizes information into tables containing rows and columns.

That probably sounds familiar if you've used spreadsheets before. And honestly, that's where my earlier impression of SQL came from.

But there's more to it than arranging information in a grid.

In a relational database, tables have defined structures, data types, and rules that determine how information should be stored. SQL provides a way to interact with that information through statements.

Instead of manually finding and editing cells, you're describing an operation for the database to perform.

The course used a table called celebs, with columns such as id, name, and age.

Each row represented a record, while each column represented a particular attribute.

Once I understood that structure, the queries started feeling less abstract.

My First Query Was Surprisingly Straightforward

The first statement I worked with was:

SELECT * FROM celebs;

Just one line.

SELECT tells the database what information to retrieve, * represents all columns, and FROM celebs identifies the table.

In other words, I was asking the database to return all the information from that table.

If I only wanted the names, I could be more specific:

SELECT name FROM celebs;

This was where I began appreciating SQL's syntax.

Rather than memorizing a complicated sequence of operations, I could express what I wanted the database to return.

Of course, SQL is much more than a few readable keywords. But seeing a statement produce the expected result made the language easier to approach.

It also introduced an idea I found interesting: with SQL, you're often describing what result you want, rather than spelling out every individual step the database must take to produce it.

Creating a Table Helped Me Understand Its Structure

Retrieving information from an existing table was one thing. Creating the table myself helped connect the pieces.

One of the exercises involved writing:

CREATE TABLE celebs (
    id INTEGER,
    name TEXT,
    age INTEGER
);

This defines a new table with three columns.

The column names describe the information being stored, while the data types specify what kind of values the columns should contain.

For example, INTEGER represents whole numbers and TEXT represents text values.

I also learned that SQL keywords are commonly written in uppercase for readability, while a semicolon marks the end of a statement.

The syntax itself wasn't difficult to follow. What mattered was understanding why each part existed.

Once the table had been created, it was time to add records.

Adding Information with INSERT INTO

The next statement was INSERT INTO.

Here's a simplified version of the kind of example I practiced:

INSERT INTO celebs (id, name, age)
VALUES (1, 'Sample Artist', 29);

The statement identifies the table, specifies the columns receiving values, and provides the values to insert.

At this point, I could see how the operations connected.

CREATE TABLE establishes the structure, INSERT INTO adds records, and SELECT retrieves information from those records.

It sounds simple when explained that way, but actually writing and running the commands helped me understand the relationship between them.

ALTER TABLE and UPDATE Taught Me an Important Difference

Two commands I found particularly useful were ALTER TABLE and UPDATE.

They both change something, but they operate at different levels.

ALTER TABLE changes the structure of a table.

For example, the course introduced a new column called twitter_handle:

ALTER TABLE celebs
ADD COLUMN twitter_handle TEXT;

The table now had an additional column, but the existing records didn't automatically have values for it.

Those missing values were represented by NULL.

UPDATE, on the other hand, changes information already stored in the table.

For example:

UPDATE celebs
SET twitter_handle = '@example'
WHERE id = 1;

This changes the twitter_handle value for the record whose ID is 1.

The distinction became clear to me:

ALTER TABLE modifies the table's definition.
UPDATE modifies data within the table.

And then there's the WHERE clause.

It's easy to overlook, but it determines which records an operation affects.

Without the appropriate WHERE condition, an UPDATE statement could modify every row.

That was a useful reminder that readable syntax doesn't automatically make a command safe to execute.

You still need to understand exactly what you're asking the database to do.

DELETE FROM: A Simple Command with Serious Consequences

Another operation I practiced was deleting records.

The course used this query:

DELETE FROM celebs
WHERE twitter_handle IS NULL;

The statement removes records where twitter_handle has a NULL value.

I learned that NULL represents missing or unknown data. It isn't the same thing as zero or an empty string.

That's why SQL uses IS NULL to test for it.

Something else stood out here.

Compare the query above with:

DELETE FROM celebs;

Removing the condition changes the effect completely. Instead of deleting selected records, the statement would delete every row in the table.

That made me think more carefully about database operations.

The commands themselves might be straightforward, but understanding their consequences is just as important as knowing their syntax.

For more substantial databases, I'd want to inspect which records match a condition before running a destructive operation.

Constraints Showed Me How Databases Protect Their Data

Toward the end of the module, I learned about constraints.

Until then, I'd mostly been working with commands for creating, retrieving, and changing information.

Constraints introduced another responsibility: ensuring that the information stored in a table follows certain rules.

The course covered PRIMARY KEY, UNIQUE, NOT NULL, and DEFAULT.

One of the exercises involved creating an awards table:

CREATE TABLE awards (
    id INTEGER PRIMARY KEY,
    recipient TEXT NOT NULL,
    award_name TEXT DEFAULT 'Grammy'
);

There are a few important details here.

PRIMARY KEY identifies a record uniquely.

NOT NULL requires the recipient column to contain a value.

DEFAULT 'Grammy' supplies a predefined award name when a new record doesn't specify one.

I found this particularly interesting because it showed that managing a database isn't only about inserting and retrieving information.

It's also about controlling what information should be accepted in the first place.

As applications grow and more records are created, those rules become increasingly important.

What Actually Changed My Perspective

Looking back at the module, I think my biggest discovery was how much easier SQL became once I approached it as a language for communicating with a database.

Before starting, I mostly associated it with database tables and spreadsheet-style work.

After completing the introductory exercises, I could see a clearer process:

You define the structure of your data, insert records, retrieve what you need, make changes when necessary, and establish rules to maintain consistency.

Each command serves a purpose.

And because the statements are relatively descriptive, it didn't take long for the basic syntax to feel familiar.

That doesn't mean I've become proficient in SQL after one session.

I've only worked through the introductory Manipulation module. I still have plenty to learn about querying multiple tables, joins, aggregations, database relationships, and writing more advanced queries.

But I now understand the foundation well enough to see where those concepts fit.

I'm also beginning to appreciate why SQL remains relevant beyond people who work exclusively with databases. Applications depend on stored information, and understanding how to inspect and manage that information is valuable in software development, cloud engineering, and troubleshooting.

Final Thoughts

I spent roughly 75 minutes working through the eleven introductory exercises, and it changed how I viewed a subject I'd been putting off for a while.

SQL wasn't quite what I'd imagined.

The fundamentals were more approachable, the statements were readable, and experimenting with them helped me understand how information is managed inside a relational database.

The more interesting challenge now is taking those concepts beyond guided exercises.

I want to create a database locally, design my own tables, work with a more realistic dataset, and see how much of what I've learned I can apply independently.

That's when I'll have a better idea of how comfortable I really am with SQL.

For now, I'm glad I finally started.

Learning resource: Codecademy — Introduction to SQL

Sometimes a subject feels more complicated from a distance than it does when you actually sit down and work through the fundamentals.

The DevOps Toolchain Every Beginner Needs

Anderson Chinedum — Mon, 05 Oct 2026 18:16:35 +0000

When I started getting deeper into DevOps, I kept coming across the same tools again and again: Git, Docker, Terraform, Azure CLI, GitHub CLI, and others.

Knowing their names was one thing. Understanding why I needed each one and how they fit into an actual DevOps workflow was different.

Recently, I decided to properly set up the toolchain I will be using for my DevOps work on Windows. I expected it to be mostly downloading applications and checking their versions.

It wasn't quite that simple.

Along the way, I ran into issues with Docker not connecting to its engine, Terraform not being recognized outside its folder, Azure CLI not appearing in an already-open terminal, and GitHub CLI working in PowerShell but not immediately inside VS Code.

Working through those problems actually helped me understand the tools better than simply installing them without any issues.

In this article, I'll walk through the DevOps toolchain I set up, what each tool does, how I verified that everything was working, and some of the problems I encountered along the way.

One thing I should make clear from the beginning: there isn't one universal DevOps toolchain that every engineer uses.

Different teams use different cloud providers, CI/CD platforms, container tools, and infrastructure technologies.

For the Azure-focused environment I'm currently working with, these are the tools I started with:

Git
Azure CLI
Docker
Terraform
Visual Studio Code
GitHub CLI

By the end of the setup, I wanted more than six installed applications. I wanted a workstation where I could actually use all of them from the terminal and start connecting them together in real DevOps workflows.

What exactly is a DevOps toolchain?

DevOps is not one application.

It is a workflow made up of different tools that handle different parts of building, testing, deploying, and managing software.

The easiest way I found to understand the tools was to stop looking at them individually and think about how they connect.

For the toolchain I set up, the flow looks roughly like this:

VS Code
   ↓
Git
   ↓
GitHub
   ↓
Docker
   ↓
Terraform
   ↓
Azure

VS Code gives me the environment where I work.

Git tracks the changes I make.

GitHub gives me somewhere to store and share those changes remotely.

Docker packages applications into containers.

Terraform lets me describe infrastructure using code.

Azure CLI lets me interact with Azure directly from the terminal.

GitHub CLI also gives me another way to work with GitHub without constantly going back to the browser.

Each tool solves a different problem, but together they form the beginning of a practical DevOps environment.

Git: tracking changes from the beginning

Git was already installed on my system, so the first thing I needed to do was verify it.

git --version

My system returned:

git version 2.56.0.windows.1

Git is a version-control system.

Its job is to track changes made to files over time.

That becomes important very quickly in DevOps because almost everything eventually becomes a file that needs to be tracked: application code, Dockerfiles, Terraform configuration, CI/CD pipelines, documentation, and more.

If something changes, Git gives me a way to know what changed, when it changed, and which version I am currently working with.

This is also why Git usually sits near the beginning of a DevOps workflow.

Before automating or deploying something, it makes sense to first have proper control over the files being changed.

Azure CLI: working with Azure from the terminal

The next tool was Azure CLI.

Azure has a graphical web portal where resources can be created and managed, but DevOps workflows should not depend entirely on manually clicking through a dashboard.

Azure CLI gives me a way to interact with Azure directly from the terminal.

On Windows, I installed it using WinGet:

winget install --exact --id Microsoft.AzureCLI

The installation completed successfully.

Then I ran:

az version

and got this:

az : The term 'az' is not recognized as the name of a cmdlet,
function, script file, or operable program.

At first, I thought something had gone wrong with the installation.

But Azure CLI had actually installed correctly.

The problem was that I was still using a PowerShell session that had already been open before the installation.

I closed PowerShell, opened a fresh session, and tried again:

az version

This time it worked and returned the installed Azure CLI version.

That taught me something useful very early in the setup:

Installing a command-line tool does not always mean an already-open terminal will immediately know where to find it.

Sometimes the terminal simply needs to be restarted so it can pick up the updated environment.

Docker: having the CLI is not enough

Docker was one of the most interesting parts of the setup.

Docker is used to package applications into containers so that they can run more consistently across different environments.

I installed Docker Desktop and checked whether the CLI was available:

docker --version

The command worked:

Docker version 29.8.2

At that point, I assumed Docker was ready.

Then I ran:

docker run hello-world

and got an error:

failed to connect to the docker API at
npipe:////./pipe/dockerDesktopLinuxEngine

The system cannot find the file specified.

This was where I learned the difference between having the Docker command installed and having the Docker engine running.

The Docker CLI was available, but Docker Desktop had not fully started the engine the CLI needed to communicate with.

After starting Docker Desktop properly, I ran:

docker info

This time I could see both client and server information.

Then I tried again:

docker run hello-world

Docker pulled the image and successfully created the container.

Hello from Docker!

This message shows that your installation appears to be working correctly.

That test was more meaningful than simply checking the version.

docker --version proved that the command existed.

docker run hello-world proved that Docker could actually contact the daemon, pull an image, create a container, and run it.

Terraform: when the application works but Windows cannot find it

Terraform gave me a completely different problem.

Terraform is an Infrastructure as Code tool.

Instead of manually creating every infrastructure resource through a cloud dashboard, Terraform allows infrastructure to be defined in configuration files.

For Windows, I downloaded the Terraform ZIP file and extracted the application into a folder.

Then I tried:

terraform -version

PowerShell returned:

terraform : The term 'terraform' is not recognized as the name
of a cmdlet, function, script file, or operable program.

At this point, I needed to know whether Terraform itself was broken or whether Windows simply did not know where the application was located.

I changed into the folder where I had placed Terraform:

cd C:\Users\<USER>\Documents\Terraform

Then I ran:

.\terraform.exe -version

This worked:

Terraform v1.16.5
on windows_amd64

That told me immediately that Terraform itself was fine.

The problem was PATH.

Windows uses the PATH environment variable to know which directories it should search when I enter commands such as:

git
docker
terraform
az

I added the Terraform folder to my user PATH.

After closing PowerShell and opening a new session, I ran:

terraform -version

again.

This time it worked from anywhere.

That was probably the clearest lesson I got from the entire setup about how command-line tools actually become available system-wide.

VS Code: where everything starts coming together

VS Code was already my main development environment, so there wasn't much installation work to do here.

I verified that its CLI command was working with:

code --version

The useful part for me was seeing how all the other tools could come together inside the VS Code integrated terminal.

Instead of constantly switching between different applications, I could use Git, Azure CLI, Docker, Terraform, and GitHub CLI from the same workspace where I was editing my files.

That made the setup start feeling less like a collection of individual programs and more like an actual working environment.

GitHub CLI: GitHub from the terminal

The last major tool I added was GitHub CLI.

Git and GitHub are related, but they solve different problems.

Git handles version control locally.

GitHub hosts repositories remotely and provides tools for collaboration.

GitHub CLI allows many GitHub operations to happen directly from the terminal.

After installing it, I verified the command:

gh --version

Then I authenticated using:

gh auth login

I selected:

GitHub.com
HTTPS
Login with a web browser

The CLI generated a temporary device code and completed the authentication through my browser.

But I ran into one more environment problem.

gh worked correctly inside normal PowerShell, but when I tried:

gh --version

inside VS Code, the terminal still returned:

gh : The term 'gh' is not recognized...

Closing and reopening the terminal did not solve it.

What eventually worked was closing VS Code completely, opening PowerShell where gh was already recognized, changing into my project directory, and launching VS Code from there:

code .

Once VS Code opened from that fresh PowerShell environment, its integrated terminal could also recognize GitHub CLI.

That was another reminder that applications can inherit environment information when they start.

If that environment changes while an application is already running, opening another terminal inside the same application may not always be enough.

Verifying the full toolchain

After fixing everything, I verified the complete setup from my terminal:

git --version
az version
docker --version
terraform -version
code --version
gh --version

At this stage, all six tools were available and working.

The versions themselves are not the important part because they will change as new releases come out.

What matters is that each command successfully returns a result before I depend on that tool later in a DevOps workflow.

Turning the setup into a real Git project

I didn't want to finish the exercise with nothing except installed applications.

I wanted the work documented and stored on GitHub.

I created a project directory:

mkdir devops-workstation
cd devops-workstation

Then initialized Git:

git init

I created a README.md documenting the tools, their versions, the commands I used to verify them, and what I learned during the setup.

After that, I staged the file:

git add README.md

and committed it:

git commit -m "docs: add workstation setup verification"

Publishing the project to GitHub

With the local repository ready, I created a public GitHub repository directly from the terminal:

gh repo create devops-workstation --public

Then I connected the local repository to GitHub:

git remote add origin https://github.com/<YOUR_USERNAME>/devops-workstation.git

I renamed the branch to main:

git branch -M main

and pushed the project:

git push -u origin main

After the push, I checked the repository status:

git status

and got:

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

At that point, the setup was no longer something that existed only on my laptop.

It had become a small documented project that I could keep on GitHub and build on later.

Check out the repository

You can find the completed DevOps workstation setup and README on GitHub:

View the devops-workstation repository on GitHub

The problems that taught me the most

Looking back, the most useful parts of this setup were actually the moments when something didn't work.

I ran into four main problems.

Docker was installed but the engine wasn't running

The Docker CLI worked, but containers couldn't run until Docker Desktop had properly started the engine.

Azure CLI installed successfully but PowerShell couldn't see it

A new PowerShell session was needed before the az command became available.

Terraform only worked inside its own folder

The application itself was fine. The missing step was adding its directory to PATH.

GitHub CLI worked in PowerShell but not immediately in VS Code

VS Code was still running with an older environment, so I had to launch a fresh instance after the new CLI was available.

None of these were huge errors.

But fixing them forced me to understand what was actually happening underneath the commands instead of just copying installation instructions until something worked.

What I took away from the setup

Before doing this, I mostly thought about installing developer tools like this:

Download → Install → Done

Now I think about it more like this:

Install
   ↓
Make the command available
   ↓
Verify it
   ↓
Test the actual functionality
   ↓
Document the setup

That distinction matters.

Docker being installed is not the same as Docker being able to run containers.

Terraform existing somewhere on my laptop is not the same as being able to call terraform from my terminal.

Azure CLI being installed is not useful if my working environment cannot find az.

And a local Git repository becomes much more useful once it is documented and pushed somewhere I can actually share it.

This setup gave me a much clearer picture of how the different tools in a DevOps toolchain begin to connect.

What's next?

The next step is to start using these tools together for more practical work: containerizing applications, managing infrastructure through code, deploying resources to Azure, and eventually working with CI/CD pipelines.

Setting up the toolchain may not be the most exciting part of DevOps.

But before building anything serious, it helps to know that the tools underneath your workflow actually work.

Check this Article out and drop your thoughts on it

Anderson Chinedum — Sat, 03 Oct 2026 13:38:06 +0000

Anderson Chinedum

Oct 2

Building Role-Based Authentication with Firebase in a React + Vite SaaS App

#firebase #react #webdev #authentication

10 min read

Building Role-Based Authentication with Firebase in a React + Vite SaaS App

Anderson Chinedum — Fri, 02 Oct 2026 09:22:27 +0000

Authentication looked straightforward when all I needed was a way for users to sign in.

It became more interesting while I was building Loomwing, a custom-fashion marketplace application with two distinct user types: customers and tailors.

A customer needs a customer experience. A tailor needs a tailor experience. But I did not want returning users to choose their role every time they signed in.

That raised a more useful architectural question:

Once Firebase knows who a user is, how should the application determine what kind of user they are?

The solution I settled on was to separate identity from application-specific profile data.

Firebase Authentication handles identity.

Cloud Firestore stores the Loomwing profile, including the user's role.

The application then uses that persisted role to decide which experience to load.

The architecture

At a high level, I separated authentication from application-specific user data.

Firebase Authentication is responsible for identifying the user. Once a user signs in, Firebase gives the application a unique user ID — the UID.

Loomwing then uses that UID to look for a corresponding profile in Cloud Firestore:

users/{uid}

That Firestore document contains the information Loomwing needs beyond basic authentication, including the user's display name, authentication provider, and most importantly, their application role.

For now, a Loomwing user can have one of two roles:

customer
tailor

This separation means the login screen does not have to decide what kind of user someone is every time they return. Once a role has been selected during account creation, the persisted Firestore profile becomes the source of truth for the application's role-based experience.

In simple terms:

Firebase Authentication tells Loomwing who the user is. Firestore tells Loomwing what kind of user they are.

Initializing Firebase

The first thing I wanted was one place where Firebase would be initialized and reused across the app.

I didn't want authentication logic scattered across different React components, so I created a small Firebase module that exports both Authentication and Firestore.

import { getApp, getApps, initializeApp } from 'firebase/app';
import { getAuth } from 'firebase/auth';
import { getFirestore } from 'firebase/firestore';

const requiredConfig = {
  apiKey: import.meta.env.VITE_FIREBASE_API_KEY,
  authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN,
  projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID,
  storageBucket: import.meta.env.VITE_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: import.meta.env.VITE_FIREBASE_MESSAGING_SENDER_ID,
  appId: import.meta.env.VITE_FIREBASE_APP_ID
};

export const firebaseApp =
  getApps().length > 0 ? getApp() : initializeApp(requiredConfig);

export const auth = getAuth(firebaseApp);
export const db = getFirestore(firebaseApp);

The getApps() check is there to make sure Firebase doesn't initialize the default app more than once.

My configuration values come from Vite environment variables instead of being written directly into the module.

For example:

VITE_FIREBASE_API_KEY
VITE_FIREBASE_AUTH_DOMAIN
VITE_FIREBASE_PROJECT_ID
VITE_FIREBASE_STORAGE_BUCKET
VITE_FIREBASE_MESSAGING_SENDER_ID
VITE_FIREBASE_APP_ID

One thing I had to understand here is that VITE_* variables are still exposed to the client bundle. They're useful for keeping configuration organized between environments, but they aren't a place for server-side secrets.

I also keep my actual .env.local file out of Git and use an .env.example file to document the variables the project expects.

Creating an account and saving the role

When somebody creates a Loomwing account, I need more than their email and password.

I also need to know how they intend to use the platform.

Right now, Loomwing has two roles:

customer
tailor

So during signup, the user chooses their role once.

The Firebase account is created first:

const credential =
  await createUserWithEmailAndPassword(auth, email, password);

firebaseUser = credential.user;

await updateProfile(firebaseUser, {
  displayName: fullName
});

await writeProfile(
  firebaseUser,
  fullName,
  role,
  'password'
);

After that, Loomwing creates the application profile in Firestore:

await setDoc(doc(db, 'users', user.uid), {
  uid: user.uid,
  email: user.email ?? '',
  displayName,
  role,
  authProvider,
  createdAt: serverTimestamp(),
  updatedAt: serverTimestamp()
});

The profile lives at:

users/{uid}

That means the Firebase Authentication account and the Loomwing profile are connected by the same UID.

I liked this approach because Firebase handles the identity side, while Firestore holds information that belongs specifically to Loomwing.

The role is one of those pieces of application-specific information.

It is stored in Firestore, not as a Firebase custom claim.

Signing in without asking for a role again

This was one of the first things I wanted to clean up from the earlier version of Loomwing.

During development, it can be tempting to have buttons like:

Sign in as Customer
Sign in as Tailor

That makes testing easy, but I didn't want that to become part of the real authentication system.

Once an account already exists, the user shouldn't have to keep telling Loomwing what role they belong to.

Email/password sign-in uses Firebase normally:

const credential =
  await signInWithEmailAndPassword(auth, email, password);

After Firebase authenticates the account, Loomwing reads the profile using the user's UID:

const snapshot = await getDoc(
  doc(db, 'users', user.uid)
);

The flow becomes:

Email + Password
       ↓
Firebase Authentication
       ↓
Firebase UID
       ↓
users/{uid}
       ↓
Saved role
       ↓
Customer or Tailor experience

The important part is this:

The sign-in form doesn't decide the user's role. The stored profile does.

That felt much cleaner than making role selection part of every login.

Google Sign-In was a little more complicated

Email/password signup already gives me a chance to ask whether someone is joining as a customer or tailor.

Google Sign-In doesn't.

Firebase can authenticate the Google account, but it still doesn't know what that person is supposed to be inside Loomwing.

The authentication itself is straightforward:

const credential =
  await signInWithPopup(
    auth,
    new GoogleAuthProvider()
  );

return await resolveFirebaseUser(
  credential.user
);

The interesting part happens afterwards.

Loomwing checks whether the authenticated Firebase user already has a profile at:

users/{uid}

If the profile exists, I load it and continue.

If it doesn't exist, the user is asked to choose a role before the Loomwing profile is created.

The flow looks like this:

Continue with Google
        ↓
Firebase authenticates user
        ↓
Does users/{uid} exist?
       /        \
     Yes         No
      ↓           ↓
Load profile   Ask for role
                  ↓
             Create profile
                  ↓
               Continue

I initially thought of this as a "new Google user" problem, but that's not quite accurate.

What really matters is whether the Loomwing profile exists.

The implementation doesn't depend on Google's isNewUser metadata. It checks Firestore.

That also covers cases where a Firebase account exists but the Loomwing profile is missing.

If the user closes the onboarding flow without finishing it, Loomwing signs them back out instead of leaving the app stuck in a half-finished authentication state.

Firebase identity alone wasn't enough

This is probably the part of the implementation that changed how I think about authentication the most.

At first, it's easy to think:

Firebase says the user is signed in, so the application session is ready.

For Loomwing, that isn't always true.

The application needs both:

Firebase authenticated user
        +
valid Firestore users/{uid} profile
        =
Loomwing application user

When Loomwing reads the Firestore document, it doesn't just accept whatever data happens to be there.

The profile is validated.

The role must be either:

customer

or:

tailor

The authentication provider must also be either:

password

or:

google

The saved profile is then converted into the user object Loomwing actually works with:

const toApplicationUser = (
  user: FirebaseUser,
  profile: LoomwingUserProfile
): User => ({
  id: profile.uid,
  name: profile.displayName,
  email: profile.email,
  role: profile.role,
  avatarUrl: user.photoURL ?? undefined,
  createdAt: profile.createdAt.toDate().toISOString()
});

The line that matters most here is:

role: profile.role

That persisted role becomes part of the real application session.

Restoring the session after refresh

The next thing I had to handle was refreshes.

Signing in successfully isn't very useful if refreshing the browser suddenly makes the application behave like the user is logged out.

Firebase gives us onAuthStateChanged() for this.

Loomwing subscribes to it when the app starts:

const unsubscribe = onAuthStateChanged(
  auth,
  async (firebaseUser) => {
    const currentRevision = ++revision;

    if (!firebaseUser) {
      if (!disposed) {
        listener({ status: 'signed-out' });
      }

      return;
    }

    const resolution =
      await resolveFirebaseUser(firebaseUser);

    if (
      !disposed &&
      currentRevision === revision
    ) {
      listener(resolution);
    }
  }
);

So when Loomwing loads, the process is roughly:

Application starts
       ↓
Wait for Firebase
       ↓
Auth state resolves
       ↓
Authenticated?
    /       \
   No        Yes
   ↓          ↓
Landing    Read profile
              ↓
         Restore session

The app stays in a loading state until Firebase has resolved that initial authentication state.

There is also a small detail in this implementation that I think is worth mentioning.

Reading the Firestore profile is asynchronous.

That means an older profile request could theoretically finish after a newer authentication event.

The revision value prevents that old result from replacing the newer state.

It's a small piece of code, but it's the kind of thing I probably wouldn't have thought much about when I was only building basic login screens.

Firestore rules are part of the auth system too

Getting somebody signed in is only one part of the job.

I also had to think about what that authenticated user should actually be allowed to read or change.

For the users collection, Loomwing first checks that the signed-in Firebase user owns the document being accessed:

function isSignedInAs(uid) {
  return request.auth != null
    && request.auth.uid == uid;
}

The profile rules then use that check:

match /users/{uid} {
  allow read: if isSignedInAs(uid);

  allow create: if isSignedInAs(uid)
    && hasValidProfileFields(uid)
    && request.resource.data.createdAt == request.time
    && request.resource.data.updatedAt == request.time;

  allow update: if isSignedInAs(uid)
    && hasValidProfileFields(uid)
    && request.resource.data.diff(resource.data).affectedKeys()
      .hasOnly(['email', 'displayName', 'updatedAt'])
    && request.resource.data.updatedAt == request.time;

  allow delete: if false;
}

A normal profile update can change:

email
displayName
updatedAt

But it can't change:

uid
role
authProvider
createdAt

That means somebody can't use a normal client-side profile update to turn:

role: "customer"

into:

role: "tailor"

I didn't want the role to be nothing more than a frontend setting.

Once the role affects what somebody can do inside the application, it also has to be treated as part of the application's security model.

Authentication doesn't mean onboarding is finished

I ran into another interesting case when I started testing real Tailor accounts.

A user could be:

Authenticated: yes
Role: tailor
Tailor profile: missing

Those aren't the same thing.

Earlier versions of the app had mock tailor data available, but I didn't want a real authenticated Tailor to suddenly inherit some placeholder profile just because a real profile hadn't been created yet.

So Loomwing looks for a TailorProfile that actually belongs to the authenticated user.

If it doesn't find one, the result stays null.

Instead of showing fake information, the application shows:

Set up your tailor profile

Opportunities, proposals, and orders stay unavailable until that real profile exists.

The actual profile editor is still a later product step.

And I'm okay with that.

I'd rather the app clearly show that something isn't finished than quietly attach placeholder information to a real account.

This also helped me separate three ideas that I used to think of as one thing:

Authentication

Who is this person?

Application role

Are they a customer or tailor?

Onboarding

Do they have all the information needed to use the features for that role?

A user can successfully complete authentication and still have onboarding work left to do.

Deploying it with Firebase Hosting

Getting everything working locally was one thing.

Getting it working after deployment exposed a couple of configuration mistakes.

The first one was the Hosting directory.

Loomwing uses Vite, so the production build goes into:

dist

Firebase Hosting therefore needs to serve that folder:

{
  "hosting": {
    "public": "dist",
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

The rewrite sends application routes back through index.html, which is what I need for the single-page application.

I also ran into an issue when deploying my Firestore rules.

At first, Hosting existed in firebase.json, but Firestore wasn't configured there.

So Firebase had no Firestore deployment target.

The configuration needed this as well:

{
  "firestore": {
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  }
}

Once that was in place, I could build:

npm run build

and deploy Hosting and Firestore rules together:

firebase deploy --only "hosting,firestore:rules"

Neither mistake was especially complicated once I understood what was wrong.

But they reminded me that getting a feature working on localhost is only part of finishing it.

Deployment is part of the system too.

What I learned

When I started working on this, I mostly thought of authentication as the part where somebody enters an email and password and gets access to the app.

After building this version of Loomwing, I don't really see it that way anymore.

The login form is probably the easiest part.

The more important questions were:

Who is this person?
What kind of Loomwing user are they?
What information do I trust?
What should they be allowed to change?
What happens when they're authenticated but their profile isn't complete?
What happens when they refresh the page?

The mental model I ended up with is:

Firebase Authentication
"Who are you?"

Firestore profile
"What kind of Loomwing user are you?"

Application logic
"What should you be able to do?"

Separating those responsibilities made the whole system easier for me to reason about.

It also gives me a cleaner foundation for the next parts of Loomwing, especially proper TailorProfiles, requests, proposals, measurements, orders, and the other role-specific workflows that will sit on top of this authentication layer.

There's still a lot I want to improve, but this version is a long way from the mock authentication flow I started with.

And more importantly, I understand why it's structured this way now.

If you're building a multi-role application with Firebase, I'd be interested to know how you've handled the separation between authentication, roles, and onboarding.

DEV Community: Anderson Chinedum

I Deliberately Broke a Git Merge to See What Happens Under the Hood

I Wanted Git to Fail. And It Did.

Setting Up the Experiment with GitFlow

Creating a Feature

A Quick Note on GitFlow vs. Trunk-Based Development

Getting the Feature into GitHub

Why I Used a Squash Merge

Time to Break Something: Creating the Merge Conflict

Creating the First Version on main

Creating a Different Version on develop

Attempting the Merge

What Was Actually Happening Under the Hood?

Understanding the Conflict Markers

There's More Going On Than Just Conflict Markers

Fixing the Merge Without Losing the Changes

Telling Git the Conflict Was Resolved

What Changed in the Git History?

The Merge Was Fixed. But Were My Branches Actually in Sync?

Using a Fast-Forward Merge

Verifying the Final State

Three Merge Strategies, Three Different Results

Final Thoughts: Breaking Things Can Teach You How They Work

Explore the Repository

I kept putting off learning SQL because I thought it would be complicated. Turns out, I just needed to start writing queries. Here's what changed my perspective. Give it a read!

SQL Was Always Just Database Stuff to Me. Then I Started Writing Queries

SQL Was Always Just Database Stuff to Me. Then I Started Writing Queries

SQL Made More Sense When I Stopped Thinking About It Like Excel

My First Query Was Surprisingly Straightforward

Creating a Table Helped Me Understand Its Structure

Adding Information with INSERT INTO

ALTER TABLE and UPDATE Taught Me an Important Difference

DELETE FROM: A Simple Command with Serious Consequences

Constraints Showed Me How Databases Protect Their Data

What Actually Changed My Perspective

Final Thoughts

The DevOps Toolchain Every Beginner Needs

What exactly is a DevOps toolchain?

Git: tracking changes from the beginning

Azure CLI: working with Azure from the terminal

Docker: having the CLI is not enough

Terraform: when the application works but Windows cannot find it

VS Code: where everything starts coming together

GitHub CLI: GitHub from the terminal

Verifying the full toolchain

Turning the setup into a real Git project

Publishing the project to GitHub

Check out the repository

The problems that taught me the most

Docker was installed but the engine wasn't running

Azure CLI installed successfully but PowerShell couldn't see it

Terraform only worked inside its own folder

GitHub CLI worked in PowerShell but not immediately in VS Code

What I took away from the setup

What's next?

Check this Article out and drop your thoughts on it

Building Role-Based Authentication with Firebase in a React + Vite SaaS App

Building Role-Based Authentication with Firebase in a React + Vite SaaS App

The architecture

Initializing Firebase

Creating an account and saving the role

Signing in without asking for a role again

Google Sign-In was a little more complicated

Firebase identity alone wasn't enough

Restoring the session after refresh

Firestore rules are part of the auth system too

Authentication doesn't mean onboarding is finished

Authentication

Application role

Onboarding

Deploying it with Firebase Hosting

What I learned

Creating the First Version on `main`

Creating a Different Version on `develop`