New to Plastic SCM?

Read this and feel at home

This guide is here to help Git users who consider transitioning to Plastic SCM.

It also shows Git users what they can get if they move to Plastic.

Plastic SCM for Git users

Plastic SCM Highlights for Git users

What is the same and what changes between Git and Plastic?

What's the same What changes

Plastic is a DVCS too. So you'll use the same workflow: you commit first (checkin) then you push your changes to the remote repo.

In Plastic you can work centralized if you want to. SVN style directly doing checkin without intermediate clone? Possible.

While coders will love DVCS, other roles like artists and designers will probably go for central.

Creating feature branches often, switching to them, switching to others...

Everything in Plastic can be done visually from the GUI. You'll end up using the Branch Explorer for all things related to branching and merging.

Push and pull branches from remote repos.

You can do partial replicas: meaning you can simply pull a branch, without bringing all the parents and merge sources, and be able to add changes and push back.

Very good merging.

Git has good merging. Merging in Plastic is even better. The merge engine in Plastic can deal with moves and renames that make Git break.

Plastic includes its own diff and merge tools too.

Plastic can handle really big files – what fits in RAM is not the limit.

Plastic is good with very big repos too.

"Remotes" – there's no such a concept in Plastic, you just push and pull the branches you want to the repos you want, no need to define "remotes" first.

Clones: you don't need to "clone" the full repo to start working on a replicated repo in Plastic. You can simply run what we call a " partial replica " which is much faster.

Then you can work on the repo, make new changes and pull back.

It is the equivalent to a shallow clone with a restricted depth but capable of pushing back.

Submodules – we call them Xlinks and they're greatly enhanced and simplified submodules:

  • Creating them is incredibly simple, with full GUI support.
  • Xlinks are capable of managing the references automatically. The tedious work to update submodules manually is gone.
  • Branches under the Xlinked directories are created automatically, making "feature branches" super simple on multi-repo scenarios.

ACL based security

How to access Git repos from Plastic and vice versa?


Plastic speaks the Git network protocol, so it can push/pull to a remote Git server. The Git server *thinks* Plastic is just another regular client.

You can use GitSync to push and pull from a GitHub repo, or any other Git server. It supports the Git protocol and also http and ssl.

GitSync does not support the file protocol yet, so you can't contribute to a local repo on your disk... unless you run a local server.

More info:


Plastic implements the fast-import and fast-export commands, which are totally compatible with their Git counterparts.

Fast-import/export commands are meant to be used for an initial import from Git to Plastic and in order to have a way to safely move away from Plastic if required. For regular daily operations GitSync is an easier choice.

Plastic SCM running as a Git Server
Plastic SCM running as a Git Server

Git clients can directly push/pull to any Plastic Server that has the GitServer feature enabled.

GitServer turns any Plastic SCM server into a full-featured Git server. This means it is a "universal connector" to plug any Git tool to Plastic (issue trackers, repository analysis tools, DevOps/Continuous Integration, code reviews and many more).

Alternatively, GitServer plays a key role helping organizations transitioning to Plastic while keeping repos in sync with other teams using Git.

It can also be used as a way to collaborate with external teams delivering repos in Git format.

Git-Plastic dictionary

While most of the underlying concepts are the same, a few things change:

Git Plastic SCM Explanation

To commit

To checkin

We just call it checkin while Git calls it commit. Just the act of submitting changes to the repo.



Each new change on the history of the repo, grouping several individual file and directory changes.



Whenever you create a repo in Plastic there's always an "empty" branch. We call it main. We could also have used "trunk" in SVN style... :P

To checkout

To update

Downloading content to the workspace (working copy). We call it "update" because we use "checkout" with a different meaning.


No equivalent on Git.

When you checkout a file in Plastic you're basically telling Plastic you are going to modify the file. It is used for two purposes:

  • To handle huge projects with >300k files: you tell Plastic what you're touching so you follow a checkout-edit-checkin workflow and Plastic doesn't have to "scan" your working copy for changes, which is a great speed improvement if your project is HUGE. (Otherwise you won't notice).
  • To handle locks: more on "exclusive checkout".

More about edit-ci vs co-edit-ci here and here .

Exclusive checkout or lock

Means locking a file so nobody can touch it. It is useful only for non-mergeable files, like binaries, images, art in a video game and so on (we would never use it for code!!!).

More here .


We don't handle rebases in Git fashion, at least not so far.

Plastic doesn't rewrite history. It is not that we're against it, it was a design decision, a philosophy. We're not religious about it so we don't discard we'll change it one day.

That being said: rebasing is a subtle topic in Git: you can only do it *before* you push (in fact many recommend not to use it ever) and most of the time it is used to be able to *understand* the history without going crazy with all the merging.

Plastic has the Branch Explorer which simply lets you understand what is going on, graphically. So chances are you don't go crazy and you don't miss rebasing.

Second: when you diff a branch with several merges, it is hard to see what you really changed on the branch and what comes from the merge... this is also solved in Plastic .



No changes here, a repo is a repo: the "database" where the entire history of the project is stored.

The difference is that in Plastic the repos are stored on a separate directory from the working copy.

And repos in Plastic are, in fact, databases: we use standard databases like sqlite, SQL Server, MySQL and more to store data and metadata.

Working copy


In Git you have the working copy and the repo on the same location. You have a working copy and a .git hidden dir with the repo. In Plastic this is slightly different since repos and workspaces are separated.

It means you can have several workspaces working with the same repo, and I mean against the same "local repo", something you can't do in Git without an intermediate repo (which changes the scenario again).

Check the Plastic Book to better understand repos and workspaces.

Plastic is not Git! - Use it as a differentiator

Long ago version control used to be considered a commodity. You just had to use one, it didn't really matter which one. But that was before the DVCS revolution and before Git, Mercurial and our own Plastic SCM changed everything.

Plastic is not based on Git, it doesn't use the same core, and it is not another layer on top of it. And you can use it as an advantage, because if version control is a competitive advantage and all your competitors use the same DVCS... what's the plus?

Git did a fabulous job educating the entire software community on branching, merging, pushing and pulling. New tools, new patterns and new best practices were adopted and everything changed.

Plastic SCM starts with all the strengths of Git and then it adds support for large files, consistent GUIs, ACL-based permissions, handles huge repos, even stronger merging, partial replica, semantic diffing and merging...

We develop the full stack - from core to GUI

We only do version control, but we do the entire version control.
Plastic is not a layer on top of an open source project, adding some GUIs here and there.
We build Plastic SCM from the ground up, from the core to the GUI.
We develop, use, and support Plastic SCM.

We build the Plastic server core, the entire branching and merging engine, the storage layer on database, the optimized network protocol, but we also develop the diff and merge tools, the GUIs on Mac, Linux and Windows, the integrations with issue trackers and IDEs... It is a lot of work for a small team like ours, but we get something in exchange: great consistency.

Developing the entire stack, from the core to the GUI, gives us the chance to get the maximum out of each new feature. Think on our integrated multi-file semantic diff that detects methods that have been moved to a different file and changed . It goes down from diff calculation, adding semantics to the algorithm, to the way in which the GUI is rendered.

Whenever we design a new feature we don't stop on the server side or the command line, we go all the way up, we think how the developer is going to use it, that's the final goal in fact.

Compare it to what you get with regular Git tools: ok, different teams on different companies collaborating together, which is great, but very often you see how GUI tools are just wrappers on the command line, they don't look and feel as if they were designed consistently, do they?

This is one of the key advantages when you use Plastic SCM: everything has been designed by the same team, and hence consistency and attention to the detail has been built-in from the beginning.

The same happens at the support level. We build, use and work every single minute with Plastic SCM. So you get engineering level support: you can access the team actually coding Plastic.