I Sat in Engineering Meetings for Two Years Without Understanding What a Branch Was

Let me paint you a picture you might recognise.

You are in a sprint review. The engineer says: “We merged the PR for the new refusal behavior on Tuesday; it is on main now.”

You nod. You write “refusal behavior shipped” in your notes. You move on.

Later that week, a customer support lead pings you. The AI assistant is refusing questions it shouldn’t. It has been doing that for four days.

You go back to the engineer. They pull up something on their screen, scroll for thirty seconds, and say: “Yeah, there was a commit on the system prompt file three days ago. Looks like it over-triggered. I can revert.”

You smile and say, “Great, thanks.”

Internally, however, you are thinking:

What is a commit?

What is a system prompt file?

How did a three-day-old change create four days of customer complaints?

And why does everyone else seem to understand this except me?

That was me for far longer than I would like to admit.

This article is what I wish someone had explained on my first day working with engineers.

Why GitHub Feels Like It Is Not for You

Most non-engineers open GitHub and immediately feel lost.

You see repositories, branches, commits, pull requests, forks, merges, issues, actions, and dozens of tabs that seem designed for people who write code for a living.

The problem is not that GitHub is complicated.

The problem is that nobody explains it using language that makes sense to the people who work with engineers rather than being engineers.

Product managers, founders, operations leads, marketers, customer support managers, and AI trainers all interact with software projects.

Yet many of us spend years pretending we understand GitHub while secretly hoping nobody asks a follow-up question.

The good news is that you do not need to learn programming to understand the basics.

You only need a mental model.

Think of a Repository as a Company Filing Cabinet

Imagine your entire project lives inside a giant filing cabinet.

Every document related to the project is stored there.

Code files.

Prompt files.

Configuration files.

Documentation.

Design assets.

Everything.

In GitHub, that filing cabinet is called a repository, often shortened to “repo.”

When someone says:

“The fix is already in the repo.”

They simply mean:

“The updated version exists in the project's filing cabinet.”

What Is a Branch?

This was the concept that confused me the longest.

A branch is simply a safe copy of the project where someone can make changes without affecting the live version.

Imagine your team is writing an important report.

You would not let five people edit the final document at the same time.

Instead, each person would make a copy, work on their section, and then submit their changes back to the main document.

That copy is essentially a branch.

The main version of the project is usually called main.

Engineers create branches to experiment, build features, fix bugs, or test ideas.

Nothing breaks because they are working on a separate copy.

What Is a Commit?

A commit is a saved checkpoint.

Think of it like pressing "Save" while writing a document, except GitHub remembers exactly what changed.

Each commit includes:

What changed

Who changed it

When it changed

Why it changed

If something goes wrong later, engineers can look through commit history like investigators reviewing security camera footage.

When someone says:

“There was a commit on Thursday.”

They mean:

“Someone saved a specific set of changes on Thursday.”

What Is a Pull Request?

A pull request (PR) is a request to merge changes from a branch into the main project.

Think of it as submitting your edited document for review.

Before changes become official, teammates review them.

They might approve them.

They might ask questions.

They might request revisions.

Only after approval are the changes merged.

A PR is less about code and more about teamwork.

It creates a record of decisions.

What Does “Merged Into Main” Mean?

This phrase used to sound incredibly technical to me.

In reality, it means:

“The approved changes have been added to the official version.”

That is it.

The feature branch was reviewed.

The team agreed.

The changes became part of the main project.

When engineers say:

“It is on main now.”

You can mentally translate it to:

“It is officially part of the project.”

Why This Matters for AI Products

In traditional software, a bug might come from code.

In AI products, strange behavior can come from many places:

Prompt updates

Safety rules

Model changes

Retrieval settings

Knowledge base updates

Configuration changes

Many of these live inside GitHub.

This means understanding GitHub is no longer just an engineering skill.

It is increasingly a product skill.

If an AI assistant suddenly becomes more restrictive, less accurate, or starts giving unexpected responses, there is a good chance the answer exists somewhere in the project history.

GitHub helps teams trace that history.

The One Question That Changed Everything for Me

For years I avoided asking technical questions because I worried they would sound stupid.

Then one day I asked an engineer:

“Can you show me where this change lives?”

That single question changed everything.

They opened GitHub.

They showed me the PR.

They showed me the files.

They showed me the comments.

For the first time, the system stopped feeling magical.

I could actually see the decision-making process.

From then on, engineering conversations became easier because I finally understood the map.

You Do Not Need to Become an Engineer

One misconception keeps people stuck.

They think learning GitHub means learning software engineering.

It does not.

You do not need to understand algorithms.

You do not need to write production code.

You do not need to memorize commands.

You only need enough understanding to follow the story of a change.

Who changed something?

What changed?

Why did it change?

When did it change?

Those four questions alone will make you dramatically more effective in technical environments.

Final Thought

For two years, I sat in engineering meetings nodding at words I did not really understand.

Branch.

Commit.

Pull request.

Merge.

Main.

Eventually I realized something important:

These terms are not advanced engineering concepts.

They are simply the vocabulary of how modern teams collaborate.

Once someone explains them in plain English, the mystery disappears.

And when the mystery disappears, you stop feeling like an outsider in the room.

You start participating in the conversation.

That is when technical projects become much easier to navigate—even if you never write a single line of code.