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 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.
Top comments (0)