Gitty

Gitty turns learning Git into a fun daily habit with a daily puzzle, visualized graphs, streaks, and instant feedback. Beginners learn concepts, not commands, in a safe, polished web app.

Comment

Inspiration

Learning Git is hard for beginners, not because the commands are complex, but because the mental model is invisible. New developers often face blank terminal anxiety and end up copy-pasting commands without understanding what’s happening to the commit graph.

We wanted to change that. Gitty was inspired by daily logic games like Wordle: short, approachable, and habit-forming. Our goal was to turn Git from something intimidating into a daily learning ritual that builds real intuition over time.

What it does

Gitty is a gamified learning platform centered around the Daily Commit that refreshes every 24 hours. Users are given different branches to start, and designated files are to collect for completing the puzzle. By using Git commands, they can switch between branches while watching a real-time visual commit graph update instantly.

Key features include: Daily Commit puzzles with instant visual feedback

A list for Git command vocabulary

Streaks and personal stats to encourage consistency

A Global Leaderboard to add friendly competition

Instead of memorizing commands, users learn by seeing what Git actually does.

How we built it

We architected Gitty as a high-performance monorepo using PNPM workspaces. The frontend is a React 18 application built with Vite and Tailwind CSS, utilizing a custom git-engine package for state management. The backend is a distributed system running on Cloudflare Workers via the Hono framework. We split it into a user-application for CRUD and a data-service that leverages Cloudflare Durable Objects to maintain real-time game states and background tasks like leaderboard aggregation. Finally, Data persistence is handled by Cloudflare D1 with a lightweight IP-based authentication system.

Challenges we ran into

Incorrect branching logic Implementing Git behavior as a puzzle engine was non-trivial. Early versions of the solver produced invalid repository states due to edge cases in branch movement and history manipulation. We had to carefully align our internal state transitions with real Git semantics to ensure puzzle solutions behaved as expected.

Integration issues between frontend and backend

Coordinating changes across two separate codebases introduced synchronization challenges. Differences in request expectations, response formats, and error handling caused mismatches that required iterative debugging and tighter interface contracts.

Formatting problems

Data exchanged between services occasionally suffered from inconsistent formatting, particularly when serializing repository states and command sequences. These issues surfaced as broken visualizations or incorrect puzzle validation on the client side.

Incorrect API calls

Several bugs stemmed from incorrect API usage, including wrong endpoints, missing headers, and improperly structured payloads. Debugging these issues required careful tracing across both repositories to ensure requests matched backend expectations.

Incorrect score updates during branching

We encountered a bug where collected files (used for scoring) were updated incorrectly when users branched or rewrote history. This exposed flaws in how state changes were propagated across branches.

Incorrect puzzle completion logic

An early version of the completion checker incorrectly required users to perform at least one git rebase to solve a puzzle. This assumption broke valid solutions, especially in single-branch puzzles where rebasing is unnecessary.

Accomplishments that we're proud of

We’re proud of how our team came together under the pressure of a 24-hour hackathon to construct a fully working, end-to-end product. In such a short time, we didn’t just build a demo but a custom, state-driven Git engine that can accurately simulate real repository behavior.

Also, we are proud of the intuitive user interface that guides users naturally through each puzzle without overwhelming them. The visual commit graph and instant feedback make it easy to understand what’s happening at every step, even for beginners. As a result, the game turned out to be genuinely fun to play, transforming Git learning into an engaging and enjoyable experience.

What we learned

Integrating a modern API with a serverless architecture provided a steep but rewarding learning curve. We moved beyond a surface-level understanding of web development to grasp the nuances of Edge Computing.

API & Serverless Integration: Building with Hono and Cloudflare Workers taught us how to architect APIs for global low latency. We had to rethink how we handled state, moving from local variables to distributed Cloudflare Durable Objects. This shift forced us to master asynchronous communication and understand how to minimize "cold starts" to keep the game feeling snappy.

Data Modeling with D1: Translating the non-linear, branch-heavy history of Git into a structured SQL format in Cloudflare D1 was a significant challenge. We learned that rigid data models fail quickly in dynamic environments; struggling with these early "negative" failures led us to design a much more flexible, state-based system that can now handle complex repository scenarios.

The Build Environment: We encountered significant friction with cross-platform binary dependencies (specifically PostCSS and Lightning CSS) when moving between Windows and macOS. Resolving these issues gave us a deep understanding of how the Bun runtime interacts with the underlying OS, teaching us that the "bridge" between different systems is often where the most critical engineering happens.

What's next for Gitty

The future of Gitty is about moving from local mastery to global collaboration. Our future roadmap includes:

Real-Time Competition: A "Head-to-Head" mode where two users race to solve the same Git puzzle simultaneously, with live updates showing each other's branching progress.

Team Collaboration & Remote Branches: Introduce "Remote Puzzles" that require teams to manage push, pull, and fetch operations across simulated remote branches, forcing users to resolve complex team-based merge conflicts.

Expanding the Git Dictionary: Include a broader suite of advanced commands, such as git clone, git config, and git add, to help users prepare for real-world scenarios.

Built With

Share this project:

Updates