Better version control, without reinventing git

Replit Projects

A Project is a set of connected, forkable Repls in a Team space. Users can fork a Repl to work on a feature in isolation, then merge changes back to the main Repl when ready, mirroring trunk-based workflows.

Since building on Replit is fundamentally different than local-first development, Project version control exists alongside traditional git. Developers of all experience levels can collaborate with the toolchain of their choice. Replit users can view all ongoing development in one place using the Project tool.

There have been no major shakeups in the software engineering workflow since git. With Replit’s realtime collaboration, we saw an opportunity to change this.

The challenge: create better version control without reinventing git. Replit users can collaborate live within a Repl, which isn’t possible in local-first development. This changes code review etiquette. Typically, reviewers make changes in their own branches rather than live-editing. But when collaboration happens live in the same environment, code review can be dramatically faster.

We developed version control that felt native to Replit’s real-time model while adopting practices like trunk-based development and stacking, all while maintaining compatibility with developers using their own IDEs and git tools.

Every Project has a main Repl as the source of truth. In this example, AnvilWebServer is the main Repl. Each team member has their own fork, like MattLegrand-07-03. Users begin by forking any Repl in the organization and are prompted to convert it into a Project.

Choosing “Fork & start a Project” converts the Repl into the main Repl and moves the user to a new fork. The Project tool opens and shows no changes from main yet. Modifications to the fork are reflected in the Project tool.