Day 1 as a Full Stack Intern: Setting Up My First Real Git Workflow

Today was my first day as a Full Stack Intern at Sandlogic, and honestly, I thought I'd spend Day 1 writing some HTML or maybe just sitting through onboarding slides. Instead, my very first task was this:

"Initialize a Git repo, set up a branch naming convention, add a .gitignore, write a proper README, create a PR template, protect the main branch, and define the contribution workflow you'll use for every single practical from here on."

No code. No React. No APIs. Just... Git. And by the end of the day, I understood why. This is the foundation everything else gets built on top of. So here's my Day 1, written the way it actually happened — including the parts where I panicked a little.

Git vs GitHub — the thing I mixed up first

Before touching anything, I had to get one thing straight in my head: Git and GitHub are not the same thing.

Git is a tool that runs on your own computer and tracks every change you make to your files over time. GitHub is a website that hosts your Git project online so other people (like my mentor, Maruti) can see it, review it, and collaborate on it.

So Git is the engine, GitHub is where the car gets parked for everyone to see.

-> Setting up the repo

I created a new GitHub repo called "FullStack_Intern", added a description, and had to make two small decisions I wasn't expecting:

'.gitignore' — what template do I pick?
Since I'm on the JS/full-stack track (Node, React, eventually Next.js), I went with the Node template. This automatically ignores stuff like node_modules/ and .env files — things that are either too huge to commit or contain secrets that should never be public.

The Branch Naming Convention

Every single practical I do from now on lives on its own branch, named like this:

week-NN-topic-slug

For example: week-01-central-repository-git-branching-strategy

The NN is always a two-digit week number so everything sorts in order, and the topic slug is just a short, readable version of what I'm working on. Simple, but it means six months from now, anyone (including me) can scroll through my branches and instantly understand the timeline of what I learned.

Writing the README

The README is basically the front door of my repo — the first thing anyone sees. Mine has:

• An overview of what the repo is for
• The tech stack I'm using
• The folder structure
• The branch naming convention (with real examples)
• The full contribution workflow, step by step

The PR Template

This one confused me at first — I actually tried to create it inside .gitignore by mistake (yeah, I know 😅). Turns out a Pull Request template is a completely separate thing that lives in a folder called .github, not inside the ignore file. Once I understood that, it was straightforward: create .github/pull_request_template.md, and now every PR I open automatically loads a consistent checklist — what the PR does, which week it's for, and a checklist to self-review before merging.

Protecting main

This is where things got real. I went into my repo's Settings → Rules → Rulesets and set up a rule so that:

• Nobody (including me) can push directly to main
• Every change has to go through a Pull Request
• Force-pushing is blocked

At first I set "Required approvals" to 1, thinking that was the safe, professional thing to do. Then I hit a wall — GitHub literally does not let you approve your own PR, no matter what. I messaged my mentor Maruti about it, and he told me I could manage my own PRs for now. So I lowered the required approvals to 0 (while keeping "PR required before merge" switched on), which meant I still had to go through the full PR process — just without waiting on someone else's click.

✨My First Real Branch → PR → Merge

Here's where I actually tested the whole system:

1. Created a branch: week-01-central-repository-git-branching-strategy
2. Added my notes for the week
3. Committed and pushed
4. Opened a Pull Request into main, using the PR template
5. Squash-merged it into main

Sounds clean when I write it like that. It was not clean the first time.

The Duplicate Folder Disaster (a.k.a. my first real Git problem)

While creating a file directly on GitHub's website, I accidentally created a folder inside a folder with the exact same name. So instead of:

week-01-central-repo-git-branching-strategy/
  └── notes.md

I ended up with:

week-01-central-repo-git-branching-strategy/
  └── week-01-central-repo-git-branching-strategy/
        └── notes.md

I didn't even notice until I actually looked closely at the file path in my browser. Lesson learned: always double-check your file path breadcrumb before committing.

I deleted the duplicate, but then when I tried pushing my local changes, Git rejected me with this:

! [rejected] (fetch first)
error: failed to push some refs

Because GitHub's copy of the branch and my laptop's copy had gone in two different directions. The fix was to git pull first to merge the two, clean up the leftover mess again, commit the cleanup, and then push. It worked.

The "Not Fully Merged" Scare

After my PR was successfully merged on GitHub (I saw the purple "Merged" badge and everything), I went back to my terminal to delete my local branch and got this:

error: The branch 'week-01-...' is not fully merged.

I genuinely panicked for a second, thinking I'd lost my work. Turns out this is a very normal, very common thing that happens with squash merges — because squashing creates one brand-new combined commit on main, Git's local branch comparison doesn't recognize it as "the same" commits, even though everything is safely there. The fix was just:

git branch -D week-01-central-repository-git-branching-strategy

The capital -D forces the delete since I already knew, for certain, that the content was safely merged (I could see it live on GitHub).

What I Actually Learned Today

Not the "correct" Git commands — I could've read those anywhere. What I actually learned is:

1. Things will go slightly wrong even when you follow every step correctly, and that's normal, not a sign you're bad at this
2. A rejected push or a "not fully merged" error looks scary but almost always has a calm, logical explanation
3. Reading the actual error message Git gives you is usually the fastest way to fix it — it often tells you exactly what command to run next
4. Setting up "boring" infrastructure like branch protection and PR templates on Day 1 is what makes every future day smoother

Tomorrow, I move on to my first actual coding practical — Semantic HTML & Accessibility. But I'm glad my first day was about building the workflow first, because now I actually understand why we do branch → PR → review → merge, instead of just being told to do it.