Moving from Git
Overview
Engineers with experience using Git will find many familiar concepts in the Mutexer Version Control System, though the terminology and some behaviors differ. This page provides a mapping between Git concepts and their equivalents in the Version Control System, along with key differences to be aware of during the transition.
Concept Mapping
| Git Concept | Version Control System Equivalent | Notes |
|---|---|---|
| Repository | Project | A project in Mutexer is the top-level container for all files, branches, and history. There is no separate repository initialization step - version control is enabled automatically for every project. |
| Branch | Branch | Branches function similarly to Git branches. Each branch maintains an independent version of the file system with its own history. Branches can be merged into other branches. |
| Commit | Transaction | A transaction is the equivalent of a Git commit. Every file operation (create, upload, rename, move, delete) is automatically recorded as a transaction with a description, timestamp, and user attribution. Unlike Git, transactions are created automatically - there is no manual staging or commit step. |
| Commit hash | Snapshot hash | The snapshot hash serves the same purpose as a Git commit hash: it uniquely identifies a specific state of the file system at a point in time. Snapshot hashes are displayed in the file explorer footer. |
| HEAD | Current snapshot | The current snapshot is the equivalent of Git's HEAD - it represents the latest state of the file system on the active branch. |
| Staging area (index) | Not applicable | There is no staging area. All file operations are recorded as transactions immediately upon execution. There is no intermediate step between making a change and committing it. |
| Merge | Merge | Branches can be merged into a target branch, combining changes from the source branch into the target. Unlike Git, there are no merge conflicts to resolve manually - the platform handles the merge operation. |
| Rebase | Not available | There is no rebase operation. The transaction history of a branch is linear and immutable. |
| Stash | Scratch section | The Scratch root section in the file explorer serves a similar purpose to a stash - it provides a workspace for temporary or experimental files that are separate from the main source tree. |
| Tags | Not available | There is no tagging mechanism. Snapshot hashes serve as the primary reference for identifying specific versions. |
| Pull requests / merge requests | Not available | There is no built-in code review or pull request workflow. |
Key Differences
Automatic transaction recording
The most significant difference from Git is that the Version Control System records transactions automatically. In Git, developers explicitly stage changes and create commits with messages. In the Version Control System, every file operation is recorded as a transaction the moment it occurs. There is no staging area, no manual commit step, and no opportunity to batch unrelated changes into a single commit or split related changes across multiple commits. This design prioritizes completeness and auditability over developer control of commit granularity.
Cloud-native architecture
The Version Control System operates entirely in the cloud. There is no local working directory, no clone operation, and no distinction between local and remote state. All changes are persisted immediately on the platform. This eliminates an entire class of issues related to synchronization, merge conflicts, and divergent local histories, but it also means that all file operations require an active network connection to the Mutexer platform.
No rebase
The Version Control System supports merging branches but does not support rebasing. There is no mechanism for rewriting or reordering a branch's transaction history onto a different base. This reflects the system's emphasis on immutable, auditable history.
Immutable history
The transaction history of a branch cannot be rewritten. There is no equivalent to git rebase, git commit --amend, git reset, or git force-push. Once a transaction is recorded, it is permanent. This immutability is a deliberate design choice that ensures the audit trail is tamper-evident and reliable for compliance and regulatory purposes.
TIP
When transitioning from a Git-based workflow, the key mental model shift is that the Version Control System handles commit tracking automatically. Focus on organizing files and managing branches rather than managing commits - the platform handles the rest.