Commits and versions

If you’ve ever worked on an arrangement with someone else, you’ve probably encountered some version of this:

“Is this the latest file?”

“I think so. I sent it Tuesday.”

“Wait — did you have the brass changes?”

“No, I was working from the file before that.”

Music projects get complicated quickly when several people are editing the same score. Someone is rewriting the strings while another person is working on the brass. A copyist is preparing parts while the arranger is still making changes. Before long, there are files called FINAL.mscz, FINAL-2.mscz, and FINAL-REALLY-FINAL.mscz scattered across everyone’s computers.

Divisi takes a different approach.

Instead of treating every saved file as a new “official” copy, Divisi keeps a history of the work. That history makes it possible to save progress, work in parallel, bring changes back together, and then publish a specific snapshot as the version the ensemble should use.

If you’re familiar with Git, the terminology will sound familiar. If you’re not, you don’t need to know anything about Git to use Divisi.

A commit is a snapshot of your work

The score you’re currently editing on your computer is your working copy.

It might be a MuseScore file, or MusicXML exported from Sibelius, Finale, or Dorico. You can continue editing that file exactly as you normally would.

When you upload it to Divisi as a commit, Divisi records a snapshot of the score at that point in time.

The snapshot includes the score itself, who uploaded it, when it was uploaded, and an optional message describing the change.

For example:

Commit: “Reworked trumpet voicings in the dance break”

You can then go back to your working file and continue editing. When you reach another useful stopping point, commit again.

The result is a history of your work rather than a collection of increasingly creative filenames.

More importantly, a commit doesn’t have to be finished.

You can commit an arrangement that still needs work. You can commit something experimental. You can commit at the end of the night simply because you want a safe snapshot before making a major change the next morning.

That separation is useful because saving your work and releasing your work are two different things.

Commits make parallel work possible

The history becomes especially useful when more than one person is working on an arrangement.

Suppose two orchestrators download the same commit. One starts rewriting the brass while the other works on the strings.

Without a shared history, the natural workflow is to wait for one person to finish, send the file to the other person, and hope that nobody accidentally overwrites someone else’s changes.

With Divisi, they can work at the same time.

Both people are working from the same starting point:

                 Commit 12
                /         \
        Brass changes    String changes
             |                |
          Commit 13        Commit 14
                \         /
                 Merge
                   |
                Commit 15

Divisi knows that Commit 13 and Commit 14 both started from Commit 12. When the changes don’t interfere with one another, it can combine them into a new commit containing both sets of work.

This means the brass arranger doesn’t need to wait for the string arranger, and vice versa.

For a large show, that can make a substantial difference. Different arrangers can work on different scenes, sections, or instruments at the same time and bring their work together afterward.

What happens when two people change the same music?

Parallel work isn’t always conflict-free.

Imagine that both arrangers change the same four measures. One changes the trumpet voicing while the other substantially rewrites the passage. There isn’t enough information for Divisi to decide which version is musically correct.

Rather than silently choosing one and losing the other person’s work, Divisi identifies the conflict.

You can open the resulting conflict score in MuseScore, decide which changes to keep, make any additional edits you need, and upload the resolved score as another commit.

The important thing is that the collaboration doesn’t require everyone to work sequentially. People can work independently, and the history keeps track of where their work came from.

There’s also a Force Upload option for situations where you intentionally want to replace the latest commit with your working copy. It’s useful when you know that your copy should become the new starting point, rather than when you simply want to avoid resolving a merge.

A version is what you release

Commits are useful while the music is being created. At some point, though, you need to tell the ensemble:

“This is the one.”

That’s what a version is for.

A version is a commit that has been published as an official release. When you create one, Divisi assigns it a version number and generates the materials that the ensemble needs: the score, individual parts, part books, and other formatted files.

You might have a history that looks like this:

Commit 12 — Finished the introduction
      ↓
Commit 13 — Reworked trumpet voicings
      ↓
Commit 14 — Added string divisi
      ↓
Commit 15 — Merged changes from another arranger
      ↓
Version 1.0 — Released for rehearsal

The commits tell the story of how the arrangement developed. The version tells the ensemble which state of that arrangement is official.

This also means you can commit freely without worrying that every change is going to produce a new set of parts.

Why not make every commit a version?

Because most of the work that happens while arranging isn’t ready for rehearsal.

You might make five changes before breakfast and another ten during the afternoon. Some will be experiments. Some will be corrections. Some might get thrown away entirely.

Those changes are still worth saving.

A commit gives you a place to record that work without turning it into an official release.

When you’re ready for rehearsal, you choose the commit you want and create a version from it.

That distinction is particularly useful for musical work because the process of arranging is rarely linear. You may try something, change your mind, return to an earlier idea, and then take the music in a completely different direction.

Divisi keeps those stages separate:

commits are for developing the music; versions are for distributing it.

What the terms mean

Term	Meaning
Working copy	The score you’re currently editing
Commit	A saved snapshot of that score
Merge	Combining compatible work from multiple commits
Version	A published commit for the ensemble
Commit message	A note describing what changed
Parts	The materials generated from a version

You don’t need to think about the underlying technology to use this workflow. From a musician’s perspective, the important distinction is simply:

Save your work as commits. Collaborate through the history. Publish versions when the music is ready.

If you’re familiar with Git

Divisi’s commit system is based on the same general ideas used by Git.

A Git commit is a snapshot of a software project’s files. A Divisi commit is a snapshot of an arrangement.

Git can merge changes made by different developers. Divisi can merge changes made by different arrangers and orchestrators.

And just as software developers eventually turn their work into a release, Divisi turns a selected commit into a numbered version with the files that musicians actually need.

You don’t need Git installed, and you don’t need to learn Git commands. Divisi handles the technical side of the process for you.

The result is a workflow that fits the way collaborative music actually gets made:

work independently → bring the changes together → release the finished music.

From working copy to the stand

The distinction between commits and versions ultimately comes down to one question:

Are we still working on this, or is this what we’re playing?

A commit says, “This is what the arrangement looked like at this point.”

A version says, “This is the music we’re using.”

That gives arrangers room to experiment and collaborate without constantly worrying about which file is “the real one,” while giving musicians a clear, numbered release to work from.

For the click-by-click first hour, see Getting started with Divisi. For how Divisi turns a version into finished parts, see Engraving.