DEV Community: Deepika Pusala

Day 2 Diaries: Semantic HTML, Accessibility & the Branch 🌿

Deepika Pusala — Tue, 04 Aug 2026 11:45:51 +0000

If Day 1 was all about setting up the "rules of the game" (Git, GitHub, branches, PR templates), Day 2 was where I actually got to play — and also where I met my first real Git troublemaker. Here's everything I learned today, written the way it actually happened. 😅

🎯 What I worked on today
Built a mini blog page using Semantic HTML
Learned why semantic tags matter (not just what they are)
Ran a Lighthouse audit to check accessibility, performance, and SEO
Accidentally created a branch named escape 🙃 and had to recover from it
Finally understood the real difference between one branch per topic vs one branch per week
🧱 What is Semantic HTML, actually?

Before today, my idea of building a webpage was: wrap everything in

tags and hope for the best. Turns out, that's called "div soup," and it's not great. 😂

Semantic HTML means using tags that actually describe what the content is, not just how it looks.

Non-semantic (bad) Semantic (good) What it tells the browser

"This is the top section"
"This is navigation links"
"This is the main content"
"This is the bottom section"

Real-life analogy: imagine a delivery box with no label — the courier has no idea what's inside or how to handle it. Semantic HTML is like labeling the box "FRAGILE — HANDLE WITH CARE" — now the browser (and screen readers, and search engines) know exactly what they're dealing with.

A tiny example from my blog.html:
html

Tech Learning Blog

<ul>
  <li><a href="#article">Article</a></li>
  <li><a href="#tips">Tips</a></li>
  <li><a href="#contact">Contact</a></li>
</ul>

Notice aria-label="Main Navigation" — that's my first taste of accessibility (a11y) in action.

♿ Why Accessibility matters (and isn't just a "nice to have")

Accessibility means making sure your website works for everyone — including people using screen readers, people who can't use a mouse, people with low vision, etc.

Simple example: aria-label="Main Navigation" tells a screen reader "hey, this is the navigation section," even if there's no visible text saying so. Without it, someone using a screen reader might have no idea what that block of links is for.

🔦 Running my first Lighthouse Audit

Chrome has a built-in tool called Lighthouse that scores your webpage on:

⚡ Performance
♿ Accessibility
✅ Best Practices
🔍 SEO

My first attempt failed instantly with this error:

Can only audit pages on HTTP or HTTPS. Navigate to a different page.

Turns out I'd opened my file directly from my hard drive (F:/FullStack_Intern/...), and Lighthouse needs a real web server — even a local one — to properly measure things like load time.

The fix: VS Code's Live Server extension. One click on "Go Live," and my file loaded through an actual local server (http://127.0.0.1:5500/...) instead of a raw file path. Lighthouse worked instantly after that.

Lesson: file:// ≠ http://, and some tools genuinely care about that difference.

🌀 The "escape" branch incident

This was the chaotic part of my day, and honestly, my favorite lesson.

While creating a new branch in VS Code, a popup appeared:

"Please provide a new branch name (Press 'Enter' to confirm or 'Escape' to cancel)"

Somewhere in there, my branch accidentally got named... escape. Yes, literally the word "escape." 😭

I committed my blog.html file onto this wrongly-named branch without realizing it, then tried to git push — and it failed, because this branch had never been connected to GitHub.

How I found and fixed it:
bash
git branch # showed: escape, main, week-01-02-semantic-html-accessibility
git log --oneline # confirmed my blog.html commit was sitting on 'escape'

The fix used a command I'd never heard of before today — cherry-pick:

bash
git checkout week-01-02-semantic-html-accessibility
git cherry-pick 4b9ea4b # copies one specific commit onto the current branch
git push
git branch -D escape # deletes the mistake branch

Cherry-pick, in plain English: "take this one specific commit from somewhere else, and copy it onto the branch I'm currently on." It's like copy-pasting one paragraph from a messy draft into your final clean document, instead of rewriting everything from scratch.

🌳 Branch strategy — the correction of the day

I originally thought each topic (HTML, CSS, JS...) needed its own separate branch. After checking with Maruti, turns out our team's actual convention is:

One branch per WEEK, not per topic.

week-01 ← ALL of week 1's topics (HTML, CSS, JS...) as commits here
week-02 ← ALL of week 2's topics here
week-03 ← and so on

So instead of opening a new branch for every single topic, I keep adding commits into the same weekly branch, and only open one PR at the end of the week, once everything's done.

📋 Git Commands Cheat Sheet (everything I used today)
Command What it does (in plain English)
git branch Lists all branches, shows which one you're currently on
git checkout Switches you to a different branch
git checkout -b Creates a NEW branch and switches to it
git branch -m Renames the branch you're currently on
git branch -d Deletes a branch (only if it's safely merged)
git branch -D Force-deletes a branch, even if not merged
git add . Stages all your changed files, getting them ready to commit
git commit -m "message" Saves a checkpoint of your staged changes, with a note
git push Uploads your local commits to GitHub
git pull origin main Downloads the latest changes from GitHub into your local main
git status Shows what's changed, staged, or still pending
git log --oneline Shows a short list of recent commits
git cherry-pick Copies one specific commit onto your current branch
💭 What today actually taught me

Not the Lighthouse scores, not even the semantic tags. What really stuck was this: mistakes in Git are almost always recoverable, as long as you slow down, check git status and git branch before panicking, and understand why an error happened instead of just Googling the fix blindly.

Also — labeling a branch "escape" by accident might be the most on-brand thing that's ever happened to me on a stressful day. 😂

Tomorrow: More CSS, and hopefully zero branches named after keyboard keys.

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

Deepika Pusala — Mon, 03 Aug 2026 15:27:36 +0000

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:

Created a branch: week-01-central-repository-git-branching-strategy
Added my notes for the week
Committed and pushed
Opened a Pull Request into main, using the PR template
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:

Things will go slightly wrong even when you follow every step correctly, and that's normal, not a sign you're bad at this
A rejected push or a "not fully merged" error looks scary but almost always has a calm, logical explanation
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
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.