SysGit Saturday #1: A Purpose-Built Collaborative SysML v2 IDE

Most SysML v2 tools start with the graph. You build your model visually, and if you're lucky, you get some generated textual notation as a byproduct. Maybe you can even edit it, though the tool probably wishes you wouldn't.

SysGit takes the opposite approach.

We started with a simple premise: SysML v2's textual notation is a first-class representation. It's not export output. It's not a secondary view. It's the source of truth, living in actual .sysml files that you can version, diff, and merge just like any other code.

But here's where it gets interesting. While you're editing that textual notation, SysGit is traversing the AST (abstract syntax tree) in real-time and rendering a graph. Change the text, the graph updates. Drag a connection in the graph, the text file updates. Create a new block visually, and the corresponding textual notation gets written back to your file.

This fundamentally changes how systems modeling can work.

Textual notation lets us build a Git integration that actually means something. When we say "Git integration," we don't mean "you can export your model to Git sometimes, if you remember..." In fact, our integration with Git is more than an integration; Git is the underlying storage pillar of SysGit. Every SysGit project is a GitHub, GitLab, or Gitea/Forgejo repository. Creating a new project? You're creating a new repo. Saving your work? You're making commits.

Your model lives as text files in version control from day one.

This means branching actually works. You can spin up a feature branch to explore a design alternative without touching the main model. Your teammate can work on requirements in parallel while you refactor the architecture. When you're both done, you merge. SysGit integrates directly into the merge workflow, handling both textual diffs and visual graphical diffs so you can see exactly what changed at the model level.

Try doing that in a proprietary modeling database using a proprietary data structure.

Who This Is For

SysGit was built for the intersection of systems engineering and software engineering. If you're a systems engineer who's spent years in graphical MBSE tools, you already understand the value of model-based approaches. What you might not have experienced is the velocity that comes from treating models like code. No more passing around model files. No more "who has the latest version?" No more merge nightmares that require manual intervention from a tool administrator.

If you're a software developer being pulled into systems work, the learning curve just got shallower. You already know Git. You already understand text-based workflows, CI/CD pipelines, and code review. SysGit brings that world to systems modeling.

But the real power shows up when you combine both perspectives. Systems engineers who want the capabilities of code workflows. Software teams who need to integrate system models into their DevOps pipelines. That's where things get interesting, and where textual notation shines.

For example, a spacecraft systems team needs to refactor a propulsion subsystem model. In a traditional tool, this would require coordination meetings, model locks, and careful timing to avoid conflicts. With SysGit, three engineers create feature branches. One refactors the thermal interface. Another updates requirements traceability. A third adds failure modes. They work in parallel, commit their changes, and merge when ready. The textual diffs show exactly what changed. No mysterious model corruption. No lost work.

Or consider a team running automated validation on their models. Because the model is just text files in a Git repo, their CI/CD pipeline can pull the latest commit, run consistency checks, validate requirements coverage, and generate reports. Every commit. Every branch. Automatically. Try wiring that up to a traditional modeling tool's proprietary database.

What about distributed teams where half the engineers prefer working textually and the other half think visually? In SysGit, it doesn't matter. Edit the text directly or manipulate the graph. Both are live views of the same model. The systems engineer who thinks in diagrams works alongside the software engineer who prefers textual precision. Same model, same repo, different interfaces.

The Textual Advantage

SysML v2's textual notation isn't just "code representation of a model." It's a designed language with its own semantics and structure backed by some of the largest engineering organizations. When your model lives as text files rather than being locked in a proprietary database, you get portability. You get transparency. You get the entire software and DevOps tooling that already exists for managing text-based artifacts, the tooling that powers the modern day knowledge ecosystem.

Grep works. Text search works. Version control actually works.

You can review model changes in a pull request just like you review code. You can write scripts that process your models. You can integrate system models into the same workflows your software team already uses.

And when using SysGit as your SysML v2 textual notation IDE, the graph is still there, still useful, still synced to your live textual mode, and  still necessary for certain kinds of reasoning. But when the text is primary, when it's real files in real version control, you're not locked into a single vendor's ecosystem anymore.

SysGit works with GitLab, GitHub, or open-source alternatives like Gitea and Forgejo. Your models live where your code lives. Your systems engineering workflow integrates with your software engineering workflow. Your model reviews happen in the same place as your code reviews.

This is what purpose-built means. Not a general text editor with SysML syntax highlighting bolted on. Not a graphical tool that grudgingly exports textual notation. An IDE that understands SysML v2 from the ground up, treats both textual and graphical views as equals, and bakes Git workflow directly into how you work.

We think this changes what's possible in collaborative systems modeling.

More to come in future SysGit Saturdays on visual diffs, CI/CD integration patterns, and real-world team workflows. For now, consider what your systems engineering practice might look like if your models were as easy to version, branch, and merge as your code already is.