DEV Community: David

Commitea now has challenges verified against your real GitHub

David — Sat, 01 Aug 2026 19:22:31 +0000

A while back I shared Commitea, my project to teach Git and GitHub in Spanish, with a repo of docs and an interactive visualizer. Since then I kept adding things — search, feedback widget, dark mode, a changelog page.

But there was still a gap between "reading how something works" and "actually knowing how to do it." So I built the piece that closes that gap: challenges verified against your real GitHub account.

What changed

Instead of reading how a merge or a Pull Request works and moving on, you now do it — in your own GitHub, with your own Git — and Commitea checks the result against the real API, not a checkbox you tick yourself.

The flow:

You connect your GitHub account (OAuth, repo scope).
You pick a challenge. Commitea generates a private repo in your account from a template (POST /repos/{owner}/{repo}/generate), pre-configured with whatever starting state that challenge needs.
You solve it locally, with your actual Git — clone, branch, commit, push, whatever the challenge asks for.
You hit "Verify." Commitea queries the GitHub API and tells you exactly what's missing, not just pass/fail. Three challenges are live right now, each verified differently:

Branches & commits — checks a specific branch exists and has enough commits ahead of the default branch (GET /repos/.../compare/{base}...{branch}, reading ahead_by).
Pull Request — checks at least one PR exists with a real description (not empty, not a single character).
Resolve a conflict — the template repo ships with two branches that genuinely conflict on the same line. Verification checks for a merge commit (a commit with 2+ parents) and that the file's final content matches the expected resolved value — so you can't just accept one side blindly.

A few technical details

Repo-per-challenge, not branch-per-challenge. I considered a single "progress" repo per user with one branch per challenge, but repo generation via GitHub's template API is built exactly for the one-repo-per-instance case, and verification stays unambiguous — no risk of cross-contamination between unrelated challenges living in the same repo.
The default branch is never assumed. Early on I hardcoded main as the comparison target and broke verification for anyone whose repo defaulted to master. Every verify call now reads default_branch from GET /repos/{owner}/{repo} first and compares against that.
Progress lives in Redis (Vercel KV), one JSON blob per user (progress:{username} → { [challengeId]: { completedAt } }), not a relational table — a single read gets everything needed to render the dashboard, and a single write marks a challenge complete. No migrations to manage for something this shaped.
The OAuth connect flow has an explanatory step before redirecting to GitHub. Clicking "connect" used to jump straight to GitHub's authorization screen; now there's a /login page first that explains what gets created (private repos, what gets read, what gets stored) and is explicit that the repo scope is broad because classic OAuth Apps don't offer a narrower option — GitHub Apps would, but that's a heavier model I'm not ready to take on yet.
The public challenge catalog (/retos) and the connection status in the header are fully static pages — they don't read cookies server-side, since most of the site is prerendered for performance/SEO. Instead there's a tiny /api/auth/status endpoint each page pings client-side to swap "Connect with GitHub" for "Dashboard" once it knows you're logged in.

Why this matters for the project

Git tutorials that stop at "here's the theory" are everywhere. What's rare is something that tells you, against your actual repository, whether you got it right — and why not, when you didn't. That's the difference between reading about a merge conflict and actually knowing what to do the next time Git throws one at you for real.

How you can help

Still a living project, not a closed course. Issues and PRs are open — especially ideas for new challenges (rebase, cherry-pick, and GitHub Actions checks are next on my list).

🔗 Repo: https://github.com/davidbc01/commitea
🔗 Site: https://commitea-web.vercel.app
🔗 Challenges: https://commitea-web.vercel.app/retos

I built Commitea: Git and GitHub explained in Spanish, with an interactive visualizer

David — Fri, 24 Jul 2026 20:46:34 +0000

When I started programming, Git was hard for me — like anything new is at first. Over time I noticed something: most of the best resources for learning it are in English. And for a lot of people just starting out, that's one more obstacle they shouldn't have to deal with.

So in my spare time I built the thing I wish I'd had back then: Commitea.

What is it?

Two pieces, designed to complement each other:

An open source repo with the full documentation in Spanish — from what a commit actually is, to how to get yourself out of trouble with rebase, a cherry-pick, or a push you regret. Every entry follows the same format: the concept in one sentence, a real example with commands, and "how this breaks" (the typical mistake people make).

A web app with an interactive visualizer (commitea-web.vercel.app) where you type real Git commands and watch, live, what happens to the branch/commit graph. It doesn't touch any real repo — it's an in-memory simulator, but the engine actually replicates real Git behavior: fast-forward vs. merge commit detection, history rewriting on rebase, blocking a branch switch when you have uncommitted changes (just like real Git does), etc.

What's in it right now

7 built-in scenarios you can run with one click and watch play out step by step: branch + merge, fast-forward, rebase, cherry-pick + reset --hard, fixing a commit made on the wrong branch, several branches merging in sequence, and stashing changes.
Full command support: branch, checkout, commit, merge, rebase, cherry-pick, reset --hard, stash (with an edit helper command to simulate uncommitted changes, since the simulator has no real filesystem), status, and log.
Site-wide search (⌘K), powered by Pagefind, indexing only the actual article content — not nav or boilerplate.
A feedback widget on every article ("was this helpful?") that stores vote counts in Redis, so I know which content needs work without guessing.
Light/dark mode, respecting system preference by default.
A changelog page, because this is a living project and I want the history of what's shipped to be visible, not buried in commit messages.

A few technical details, if you're curious

The site is built with Astro + Tailwind v4, no UI framework — everything interactive (the terminal, the visualizer, the search modal) is vanilla JS inside Astro components.
The content doesn't live duplicated in the website's repo. There's a custom Astro Content Layer loader that pulls the .md files straight from the public GitHub repo at build time, so the repo stays the single source of truth. A GitHub Action in the public repo pings a Vercel deploy hook on every content push, so the site rebuilds itself automatically.
The graph renders as SVG with incremental DOM updates — nodes and edges are diffed by a stable id and their attributes updated in place, instead of destroying and recreating the whole SVG on every command. That's what makes the transitions actually animate instead of just snapping into place.
The feedback endpoint is the only non-static route on the site — a single Vercel serverless function (export const prerender = false), everything else is prerendered HTML.

How you can help

This is a living project, not a closed course. If you get stuck on something that isn't documented, or spot a mistake, issues and PRs are open. The more real questions it collects, the more useful it becomes for the next person who hits the same wall.

🔗 Repo: https://github.com/davidbc01/commitea
🔗 Site: https://commitea-web.vercel.app

If you know someone learning to code (or someone who's been at it a while but never quite got rebase), this is for them.

Hello, dev.to! 👋 Full-stack dev building in public

David — Thu, 23 Jul 2026 16:59:53 +0000

Hey dev.to! 👋

I'm David, a full-stack developer specialized in Laravel, Livewire, Alpine.js and Tailwind.

For the past 3 years I've been job hunting as a Laravel dev while building my own products on the side — right now I'm deep into WorkoutNote, an app connecting personal trainers with their clients, currently in closed alpha with real users. I'm also co-building Snipply with a friend.

I'll be sharing my build-in-public journey here: the wins, the bugs, the late nights, and everything in between. If you're into Laravel, indie hacking, or just want to talk shop, say hi!