Project Repos, Branches, and a Non-Coder's Git Education

I am not a coder. I did not grow up with terminals, merge conflicts, or .gitignore files. When the agent started talking about "initialising a git repo" I nodded along and assumed it was developer overhead — the kind of thing real programmers do so they can push to GitHub and impress each other.

I was wrong. Git repos are not overhead. They are project structure you can see.

Before the repo policy, every project lived in a folder with no rules. Files accumulated. Old experiments sat next to working builds. There was no way to tell what was current, what was abandoned, or what had been tested and proven. The whole /root/projects/ directory was a long shelf of unordered boxes.

Two lines in the memory file changed that:

Prefer git-based workflow for projects: initialise a local git repo with .gitignore (excluding generated artifacts), use main branch for stable builds and feature branches for experiments, with commits for every change.

Every new project under /root/projects/ should start as a local git repo with a .gitignore and a clear README.md. The README must explain what the project is, how to run/use it, and include a small directory tree.

What changed

Repos as project containers. Every project now starts with git init. That single command draws a box around the work. Everything inside the box is tracked. Everything outside is not part of the project. Before, a "project" was a vague collection of files. Now it is a unit with a name, a boundary, and a history.

Main is for what works. The main branch holds the stable, verified state. If I want to experiment — try a new layout, rewrite a component, test a different approach — that lives on a feature branch. If the experiment fails, delete the branch. The main line stays clean. This was the hardest concept to internalise because it felt like extra steps. In practice it removes the fear of breaking something that works.

Commits are checkpoints, not publishing. Early on I thought commits were for pushing to GitHub. Now they are the opposite of GitHub overhead. A commit is a save point I can return to. "Implemented the auto-scheduler" is a commit. "Added daylight calculation utilities" is a commit. Each one is a named, reversible step. I can rewind to any of them without losing everything.

.gitignore separates signal from noise. Generated files — node_modules/, dist/, .venv/ — used to clutter every project listing. The .gitignore file excludes them. Now when I look at a project, I see only the source files that matter. It is a small thing that changes how clean the workspace feels.

README as the front door. Every project now has a README.md that explains what it is, how to run it, and what the folder structure looks like. The directory tree in the README is the most useful part — it makes the project scannable at a glance. I no longer open a project folder and wonder what everything is.

How it looks now

A typical project starts like this:

mkdir project-name
cd project-name
git init
echo "node_modules/\ndist/\n.env" > .gitignore
echo "# Project Name\n\n..." > README.md
git add .
git commit -m "init: scaffold project structure"

Work happens on main for small changes. Bigger features get a branch:

git checkout -b feat/new-architecture

When the branch is stable, it merges back into main. If it stalls, it sits on the branch without polluting the working line. No GitHub remote unless there is a reason to share.

What I wish I knew earlier

Three things a non-coder should know about git:

You do not need GitHub. Local repos work perfectly. Remote is optional. The value is in the repo itself, not the server.
Branches are not scary. A branch is just a label on a sequence of commits. Creating one does not duplicate files. Switching between them changes what you see in the folder. That is it.
You cannot mess up irreversibly. Almost every git mistake has a recovery command. git reflog shows every move you have made. As long as you have committed at some point, the work is findable.

A year ago I would have said "git is for developers." Now I say it is for anyone who wants to know what their project looked like last week, what changed, and whether the experiment was worth running.

It is not developer overhead. It is project structure you can see. And for someone who does not write code for a living, that turned out to be exactly what I needed.