New to Plastic SCM?

Read this and feel at home

This guide is for Git users who are considering 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 when you move to 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 use the Branch Explorer for all things related to branching and merging.

Push and pull branches from remote repos.

You can make 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.

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 huge files – what fits in RAM is not the limit.

Plastic is good with huge 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 of 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 used for an initial import from Git to Plastic and 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 into Plastic (issue trackers, repository analysis tools, DevOps/Continuous Integration, code reviews, and many more).

Alternatively, GitServer plays a key role in helping organizations transition 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 terms

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 a commit. This means 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.

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 telling Plastic you will 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. 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 in 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 built 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 the 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 moved to a different file and changed . It goes down from diff calculations, adding semantics to the algorithm, to how 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 will use it, that's the end goal.

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 of using Plastic SCM: everything has been designed by the same team, and hence consistency and attention to detail have 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.