Hi.
Please suggest a suitable version control for a team: Plastic SCM,Git,SVN,…
and say about your experiences
All of the above work fine depending on what you’re doing. Lots of info on the internet about why you might choose any particular one over another.
I use BitBucket with Git and handles my needs for my personal stuff.
At work we use Mercurial on our own server.
1 Like
There’s also Unity Collab, which I think they’ve rebranded recently to Unity Teams, which is all done through the editor.
1 Like
Does it remain free in the future?
Over the years I’ve used several version control systems in professional and non-professional settings:
SourceGear Vault - don’t bother. It costs money, and honestly it’s not that great. I never used it in Unity, and wouldn’t suggest people to.
TFS - I actually really like Team Foundation Server. But holy god is setting up and maintaining the server a giant pain in the ass. In a large team setup, that is a microsoft house, this is actually a really good option. If you’re a small team, working in a mixed technology house (I’d call Unity mixed), not so much. We used this on our projects for a while because my partner was familiarish with it… we’ve since migrated away though due to many many issues.
SVN - I’ve used various implementations of SVN over the years. It really shows its age these days. It’s perfectly fine and easy to set up as well as understand the concepts. For a small team it’s perfectly suitable. I won’t actually suggest you go this route though if only because the next one is better IMO. The problem with the next one is the learning curve… and if you don’t want to deal with said learning curve… this is definitely the runner up. It’s easy and straight forward.
Git - OK… let me first start out with I’m not a git-evangelist. I think git has many flaws including difficult learning curve, a huge list of nomenclature you have to learn (which all seem to buck the common nomenclature all other VCS systems tend to share… cause of course it does), and the fact that for years GUI systems for it sucked really gimp it IMO. Some might argue a real programmer should be able to handle the terminal… I say, yeah, but my team consists of non-programmers as well!
Hell even today the gui’s that exist for git are largely crap.
But I’ve come to really like SourceTree from Atlassian! Even my artist find it’s sort of simple to use.
So… I’m not going to evangelize to you why git is so awesome. You’ve probably heard that a million times on the internet. Instead what I’m going to say what I think is the key feature of git that I like for my team of mixed users that include non-programmers.
-
distributed - you don’t need a dedicated server for it… or if you want one there’s tons of free options out there for you.
-
simple branching - this right here is why I like it. Branching and mergin in git is way cleaner than in the others I listed above.
I’ll say this, in the professional dev-houses I worked in using TFS, Vault, and SVN… we seldom if ever branched just because it was a cluster f of chaos for all of the devs. If a branch ever was created, the VCS guru of the office would be the only one that did it… and it was usually used only for release branches.
In git though since really you’re always working in branches (it’s distributed, even if you’re on the same named branch, you’re technically still in your own branch). It becomes sort of second nature.
And this allows for a key feature I like.
I stick my artist/designer on their own damn branch
So I’m the VCS guru in our team.
So what I’ve implemented a modified ‘gitflow’ for my 2 man team on this specific project (which expands to multiple team members relatively easily).
I have a branch subset called ‘workflow’. Here is where I stick people who really don’t know how VCS/Git works, and constantly step on my damn toes.
See the problem that kept happening in other VCS systems is that when ever Andy would get latest, or submit his stuff… if there was a conflict he’d just shove it on through. Overwriting stuff and breaking our code base. And getting him to not do this and create a safer workflow was near impossible since the tools weren’t flexible enough to make such a workflow make sense to him.
So I kept having to repair stuff when he’d submit… if I even noticed it.
With Git on the other hand… I created him his very own little branch, workflow/andy. This is where he stays. He never leaves that branch.
What I then do as the VCS guru of our team. I pull his branch every once in a while. And then I merge it into ‘develop’. When doing so I control the conflict resolution. I know first hand that a conflict occurred, and I deal with it. Instead of having to guess if something occurred… I know for a fact.
I also operate in my usual gitflow (feature branches), and I’ll merge those into develop as I move along.
By doing this I keep ‘develop’ stable, and I’ll merge that back to ‘workflow/andy’ so he gets full latest. I get to control the stability of the project.
…
In due time once Andy is more familiar with git, I’ll then introduce him to feature branches. But I still would keep him in his own workflow sub-branch. So he might do something like ‘workflow/feature/SomeFeature’ which branched from ‘workflow/andy’. But that’s in the future… not yet… he’s not ready.
3 Likes
I know git and prefer to work with git but I think that it can create problems in unity when you or your teammates need to change materials or prefabs, binary data, etc
binary data can cause bloat. But this is common to nearly all VCS systems out there. And that’s why Unity has the ‘force text mode’ feature in the project settings to force most things to be text and not binary.
The binary stuff still is an issue. Like textures. But like I said, this is the same in SVN and the sort. The real big difference is because it’s distributed, that bloat is pushed to all nodes in the team, rather than just the server. Of course… really just the VCS guru of the team should have all branches fetched on their machine, and each client should only have the branches that pertain to them specifically. Which mitigates some of that big data to an extent.
And of course git has ‘big data’ add-ons.
2 Likes
Bitbucket + Visual Studio Git plugin. No need to download SourceTree. Commit and push right from an IDE!
And also set asset serialization to “Force Text”, makes file comparison a lot easier.
1 Like
I’d say go with git if you want a distributed model, and go with svn if you want a server model. Depends on what your team is like. If it’s just you or if there’s just programmers in the repo, go with git all the way.
lordofduct’s correct about everything - git’s nomenclature is absurd. Checkout is insane. But the underlying model is powerful enough that you can do pretty much whatever you want to do with it.
I don’t think git scales to very large teams with a lot of artists. In those instances you need something that supports locking un-mergeable files (psds, animation files, scenes)
SmartGit’s good! I like it a lot more than SourceTree, and our artists seem to figure it out.
Collaborate was a piece of garbage last time I looked at it. Having an in-editor only version control system with a small user base is probably the worst idea anyone at Unity has ever had. You’re simply not going to be able to fix hard problems when they show up.
That the window was small, cumbersome and ugly, and that it just straight up lost data didn’t help. The sheer gall of Unity asking money for what’s probably the worst VCS out there is staggering.
2 Likes
I haven’t used Unity Collab/Teams before. I don’t ever plan on it either.
Primarily for the same reasons @Baste talks about.
A small user base, and niche market space, just means horrible support.
If they really wanted to supply a VCS built in to Unity, they should have just developed plug-ins for existing VCS like git/svn/etc. (from what I can tell plastic scm has this… I guess they have free versions today… oh and perforce. I mean srsly? No built in support for the most common VCS’s out there?).
Maybe develop some tools that massage the data appropriately for said version control systems as well. The fact I have to manually go in and configure all the stuff for my VCS is weird. It’s not a whole lot, just turn on visible meta files, force text mode, etc… but I mean, that could be streamlined way more, and their tutorial doesn’t even include the force text mode thing:
https://docs.unity3d.com/Manual/ExternalVersionControlSystemSupport.html
Sure, you don’t ‘have’ to. But it really makes dealing with conflicts that much easier.
I’ll have to take a look at it.
hmm…I’ll have to look into this. I use sourceTree now, but if this works better, might like it more.
I used to use SourceTree as well, but it felt kinda slow for me (I am on Windows). Using “VS + Git” workflow felt more fluid because I no longer had to jump between 3 programs (Unity, Visual Studio and SourceTree).
I usually like built in support in my IDE, and technically speaking because both the VS git plugin and SourceTree really are just gui forwards of the underlying Git you can use them in tandem with one another.
The main reason we use SourceTree as well is that my artist doesn’t use Visual Studio (cause he doesn’t code), and when we used TFS loading up Visual Studio was slow on his machine (he’s in Japan right now for work and has to work on a low powered laptop).
This also goes for even myself. Because if I have to do anything for the source control I have to open my project and load up Visual Studio. Though technically I always have it open for my primary project, I also have multiple other projects going at the same time for work that use Git. And I don’t always also have those open too. So I end up jumping around a lot anyways…
I mean look at this madness… and today is a slow day:
So really what I mean… in the end… you can use them both in tandem.
Back when I was using VS, it’s git plugin regularly ground my computer to a halt. I guess it wanted to index everything to help? So that wasn’t an option.
On force text, I believe that’s been the default serialization mode for a while now, so they probably felt like it wasn’t needed in the manual anymore?
It wasn’t in the manual years ago either:
We (have to) use TFS at work, with literally all the enterprise systems and tools available and connected.
It’s frightening powerful (at least for me), all the systems and tools from the Microsoft universe that can be combined with it. It’s really unbelievable how everything is connected and it takes some time to really get an idea what it’s all about.
Big downside in our case: strict rule set and configuration given by the company. We’re not allowed to change it and have to figure out weird workarounds for Unity-related stuff and make some agreements in order to use Unity with it. And this still causes some problems, because Unity wasn’t even considered when these configurations were made. And it won’t change, as Unity is only used by a few of the people here.
One example: file locking functionality is great. But Unity ignores this, removes locks and this can mess up alot of things because these changes will not be properly recorded.
It’s also a bit cumbersome to manage Unity projects with TFS in general, so it’s mainly done by one person.
Personal preference is git. I mainly use SourceTree, sometimes the command line for very special and advanced stuff.
I can highly recommend to follow the (already mentioned) gitflow, it’s also easy to set it up by just hitting the button once you cloned the project. Then, just play by the rules.
1 Like
If anyone is looking for a simple approach, I have a git repository created at Visual Studio Team Services and I am using Visual Studio’s integrated git cilent. There is basically nothing to set up, it is free and really easy to use.
I must say that I am the only person in my team, so I am using version control mainly just for a backup, but I think it can handle some more advanced scenarios as well.