Ask a SysML v1 team how they handle two people editing the same model at once and you'll usually hear a wince. The model lives in a repository or a big binary file, locking is coarse, and "merging" two branches of work often means one person manually re-keying their changes on top of the other's. Diffing a change usually means comparing two exported images and squinting. That whole class of pain exists because the model was never really text. SysML v2 changes the substrate: the model has a defined textual notation, so the files you commit are human-readable source. That one shift is what makes real version control possible, and it's quietly one of the most consequential things about the new language.
Why v1 fought version control
The obstacle in SysML v1 was never that engineers didn't want branches and diffs. It was that the model's canonical form was diagrams and an XMI serialization underneath them. XMI is technically text, but it's machine-generated XML full of internal identifiers, ordering that shifts on every save, and layout data tangled up with semantics. Commit two independent edits and Git sees thousands of noise changes with no way to tell a renamed port from a moved diagram box. A three-way merge on that is worse than useless, so teams fell back to locking, and locking kills parallel work.
The result was a culture gap. Software teams had spent twenty years building branching, pull requests, code review, and continuous integration around plain-text source. Systems modelers watched all of that from the outside because their primary artifact couldn't participate.
What the textual notation actually buys you
SysML v2 defines the model in a .sysml textual form that sits alongside the graphical views rather than under them. The text is the source; diagrams are one projection of it. Because those files are clean, human-readable text, every ordinary Git workflow applies without special tooling: branch, commit, diff, blame, open a pull request, resolve a merge conflict line by line. A reviewer can read a change as a normal diff and see that an interface was renamed and a requirement retightened, instead of hunting through a picture.
This is not only a convenience. It moves the model into the same tooling universe as the code, the requirements, and the pipelines around it. A model change and the software change it drives can live in the same pull request, get reviewed together, and land together. That is a meaningful step toward an actual digital thread, because the links stop being a nightly export job and start being how the work is done.
Diff, merge, and review in practice
The everyday mechanics look a lot like software review. You cut a branch to add a subsystem or refine an interface. You commit as you go, with messages that explain intent. When you open a pull request, a colleague reads the textual diff, comments on specific lines, and approves. If someone else touched the same package in the meantime, Git attempts a three-way merge, and because the notation is line-oriented text with real structure, most merges resolve automatically. The ones that don't surface as ordinary conflict markers you can reason about.
Tooling has grown up around this quickly. The reference implementation from the SysML v2 Submission Team ships a pilot that reads and writes the textual form. Sensmetry's Syside adds editor and command-line tooling, including a check command teams wire into CI. Vendors are converging from the diagram side too: Dassault's Cameo and CATIA Magic line, Siemens with Teamcenter, and newer entrants such as Dalus all expose or build on the SysML v2 textual form so models can be stored and versioned as files. The common thread is that the file, not a locked server session, becomes the unit of collaboration.
Continuous integration for models
Once the model is text that a parser can read, you can run checks on every change, the same way software teams gate every commit. The obvious first gate is validity: run the SysML v2 checker in CI so every pull request is parsed and validated against the spec before it can merge. A model that doesn't parse never lands on the main branch. That alone removes a whole category of "the model is broken and nobody noticed" incidents.
From there the pipeline can do more. You can enforce modeling conventions, naming rules, or required traceability links with scripted queries against the model. You can run consistency checks that flag a requirement with no allocation, or an interface with a dangling connection. Teams already pushing further generate downstream artifacts from the model on merge: interface documents, review reports, or inputs to a design tool. Dassault has shown pipelines that carry a merged SysML v2 change through to automated design steps. The point is that the model stops being a thing you inspect by opening it and becomes a thing your pipeline continuously verifies for you.
What models-as-code won't solve
It's worth being honest about the limits, because the Git analogy can oversell itself. Text-based versioning makes merges possible, not free. Two people who restructure the same package in incompatible ways will still hit real conflicts that need a human who understands the design, not just the syntax. Semantic conflicts are worse than textual ones: two changes can merge cleanly and still contradict each other in meaning, and no line-diff will catch that. You need model-level validation for that, which is exactly why the CI checks matter.
There's also a skills gap. Branching strategy, pull-request discipline, and CI hygiene are second nature to software engineers and genuinely new to many systems engineers. Adopting the tooling without adopting the habits gets you a repository full of giant, unreviewed commits that happen to be in Git. And tool maturity is uneven. The notation is stable, but round-tripping between a textual workflow and a vendor's graphical editor, preserving layout and comments across that boundary, is still rough in places. Diagram layout in particular is data that doesn't diff meaningfully, so teams have to decide what to version and what to regenerate.
None of this is a reason to wait. It's a reason to treat version control as a practice you build deliberately, not a feature you switch on.
Bottom line
SysML v2's textual notation finally lets systems models live in the same version-control world as the software they describe. Diffs become readable, merges become tractable, and CI can validate every change before it lands. The payoff is real: parallel work without locking, reviews that actually review, and a digital thread held together by commits instead of exports. Just don't mistake the plumbing for the discipline. Git gives you the mechanism; branching strategy, review culture, and model-level checks are what turn it into trustworthy configuration management. Start small, put a validity check in CI on day one, and let the habits catch up to the tooling.