Background
Replit is cloud-native and multiplayer by default, so collaboration is in its DNA. However, I often found myself frustrated when working live with others, as we were breaking each other's environments while typing. This experience collision is unacceptable for professional software teams and is what inspired my idea for Replit Projects. With Replit's cloud dev environment architecture and real-time collaboration capability, we saw an opportunity to redefine how teams work together.
Architecture
A Replit Project is a collaboration primitive that allows teammates to work on an app together without interfering with each other's environments. Structurally, it is a collection of Repls that have shared version history. Collaborators can fork a source Repl, work in their own environment, then merge changes back when ready. It is built on Git, so it is essentially a centralized, cloud-native version of trunk-based version control.
A key benefit of the project primitive is that all ongoing work is viewable in one place. You can see the current state of main and all downstream development forks. These Repls remain cloud multiplayer environments, so you can see who is coding live in them, giving each Repl a sense of place. You can view your entire team's location live on the environment tree.
One key principle in developing Projects was creating a modern version control tool for teams without reinventing Git. While retaining compatibility with existing tools and workflows, we designed version control to feel native to Replit's real-time model. This means accommodating live collaboration in ways that traditional systems, optimized for local-first development, don’t handle well. For example, live collaboration dramatically reduces the amount of process associated with code review, making changes faster and more direct without requiring separate branches for minor edits.
Workflow
To create a Project, you start by forking any Repl that you have created and opting in. This converts your original Repl into the main, "source of truth" Repl for the Project and creates a new development fork. After making changes, you or a reviewer can use the Project tool to review diffs and merge them back into the parent Repl when ready. While this is typically the main Repl, arbitrary forking and merging is supported.
One goal was to abstract away Git's complexity for less experienced programmers. One way we attempted this was by abstracting away the concept of commits in certain situations. The absence of commits in a development fork signals that a user might prefer not to care about committing, so we provide an affordance to directly merge changes (which creates a commit automatically behind the scenes). This approach makes Projects approachable for a wider audience without sacrificing power for advanced users.