Source Control recommendations

Hey Forum,

For Work, I'm currently looking into Source Control Tools and which one we should use in the future for our Dev-Pipeline.
While research, we found these three possibilities, which would suit our requirements on first glance.

Bitbucket
PlasticSCM
Github

Now i want to ask, if anyone of you has experices with these tools and can suggest, which one we should use in combination with unity. it should work with the Unity Cloud Building system.

Many Thanks in advance,
Dextex / Mike

 

Those are different things.

Bitbucket and Github are websites that you can use to host your stuff through git.
PlasticSCM is both a host and a source control system.

So you probably should do more research.

 

So you probably want to look into git vs mercurial vs SVN. You will want to look into git lfs if using git.

Then you need to look into hosts for your given source control choice, which is seperate.

These are not the same things as each other.

 

Git. That's the version control system. Github and bitbucket are sites that allow you to store git repositories.

 

you cost money for private repos and bitbucket have 10 gig limit (last I checked) devops is a nice alternative. Free up to 5 members. No hard upper limit. Microsoft will investigate your repo if it grows too big.

1 gig per commit maximum

 

I know Git is the cool kid right now, but I prefer SVN for solo or small teams. It is really simple to set up your own SVN server, so you don't need to worry about the very small storage limitations all the Git hosting services put on your projects. So you don't need to separate your assets from your code, or worry about whether you're checking in a new asset which is too big. You can just check everything in without worry.

The branching/merging advantages of Git vs SVN don't usually come into play for small teams or solo projects either. My 2 cents.

 

With git you can mid story branch off while having modified files and commits these to new branch with ease. Stuff like that makes git valuable even for one man teams

 

I know, and it is really cool. I've just never once needed to do that in the last 9 years of being a solo indie with Unity. If it is important for your projects, you won't see me telling you not to use Git.

And I never meant to say there is anything wrong with Git anyway. My main problem is really with services like Bitbucket, which charge you per user to the same repository, and act like 10GB storage is somehow not outrageously small for a "Premium" tier account in 2021.

Spoiler

In my case, for $25 a month I've rented my own server, with several TB of storage. I run my network game test server on it, a teamspeak server, and my SVN server which can handle unlimited users and effectively unlimited repository size. It works well for me, is pretty cost effective, and no hassles worrying if I really should check in these music files or large textures and models into the repository. Less headache. But that is what works for me, it won't necessarily be optimal for everyone else.

 

I use the ease of branching all the time actually. I guess branching is a mindset you get when working alot with distributed versioning.

Give devops a chance, no limit in size, our repo is 100 gigs now. Only limit is 1 gig per commit. And free up to five members.

 

10GB is not at all outrageously small for a CODE based repository which is what they are selling. A typical large team with 50-100 so developers who use git for a project that lasts a few years and don't store binary data in the repository won't come anywhere near that limit.

Given all the whitespace 1 million lines of code fits in a few megabytes. Remember git only stores changes.

The Linux kernel has been developed over 25 years by thousands of contributor, it is 1.5GB.

When I was at Oracle we had a repo worked on by ~500 developers for many years, there was plenty of mistaken binary check-ins, and large data/test files, it was around 7GB.

Sure the windows git repo is 300GB+ but that's not a typical case even for a large organisation and I expect there is a a lot of binary cruft in there.

---

To be clear I'm not saying it is suitable for bigger projects in Unity with all the binary assets, but that's not what they are targetting. The sizing makes perfect sense for their target users.

I think the limit is a pragmatic one, git performance becomes much worse as repository size grows and hosted providers are probably not wanting to bring themselves that headache. Microsoft put in thousands of hours of engineering effort to get their 300GB repo to work well.

 

I know, that's actually my point. So now you've got to separate your code from the rest of your assets in order to check it all into your version control system. What a hassle, and they are charging for the luxury of that hassle. 10GB is outrageously small for a $10 USB thumb drive, let alone a premium account for anything.

In my case, I add anything to my project, any asset, code or not, I just do

Code (csharp):

1. svn add <path to folder>
2. svn commit

And I don't have to even think about it, how big it is, what kind of files it is, etc. No fuss

 

I don't think its right for a large Unity project.

EDIT: If SVN is right for you thats great. It is a fine tool. I don't think it scales well to large teams doing lots of simultaneous feature development, but thats not relevant if you don't have a large team.

---

And as per my edit above, the bitbucket limit is almost certainly not about storage space, they host tens (probably hundreds) of thousands of free git repos. Its about git performance as repo size grows. They would likely need to re-engineer their systems to support very large repositories in a performant and cost effective manner that is suitable for paying customers. I guess they made the decision that it is not worth it.

 

Git LFS fixes the binary file problem

 

How large of a team are we talking about here?

 

To be clear I was sayng I don't think bitbucket is right for a large Unity project. Git is a workable solution.

At Illuvium we've been running wtih Perforce Helix hosted by Assembla becasue it was supposed to be more artist friendly, but the performance is not great, and the branch/merge processes are much inferior... whats more the artists stuff up as much as they do with git

We are looking at moving back to our own git servers.

 

Git with LFS works well for a code oriented team like ours. We buy art assets and they don't change much over time.

I guess though that artists don't versionen their art in the main repo? If I had artists on the team I would have their art workflow being versionen seperate and then incorporate their work as binary files using git LFS

 

One of the biggest benefits of git is how lightweight the branching process is. Its no trouble at all to use a feature branch based workflow where you create a branch and pull request for each feature.

As you scale it becomes more and more useful to use such approaches.

But there's no hard numbers. I used this on Platformer Pro asset which only had 1 core developer (me ) and a few contractors here and there. At a team size of 20+ devs I'd say its trending towards the best approach... but I don't want to get in to a debate on VCS workflows

 

On perforce we had a several art streams (if not familiar perforce stream is basically a branch) which were merged by the lead artists in each area to the core art stream. This core art stream was then merged by the lead tech artist in to the mainline.

We will likely do something similar with git.

EDIT: As you suggest there was also an art versioning process outside of perforce/git for in progress art that hadn't reached the game ready state, but we do want to get the artists as close to the game as we can (for fast iteration).

 

I'm just curious as I haven't had to deal with branching yet even though it's come up on occasion as in the past I have almost always worked on my own projects. You mention git branching is lightweight. What about svn?

 

If you have 10 minutes this has a good breakdown: https://softwareengineering.stackex...-the-difference-of-branch-between-svn-and-git

But in short SVN branches are not lightweight. If you want to do feature based branching then you probably don't want to use SVN. But this workflow isn't the be all and end all, particularly for a solo dev or small team. Sometimes I just use it ouf of habit because a lot of the work I do is in a context where it does make sense.

 

When I worked at a previous company that did a lot of branching with SVN, the branching was the easy part. It isn't lightweight as far as disk space, but creating the new branch based off the old one was pretty trivial to do as far as running commands.

The big hassle comes with backporting changes from one branch to another, and merging branches. It was basically a pretty manual process.

Spoiler

So for example, at that company we would have several branches of the same product all under development at the same time. We'd have Trunk branch, some future alpha version branch, the branch for whatever version which was near release, and then a series of legacy branches for software versions still under active support.

When any change was being added, devs mostly worked off of Trunk. Then backported the change to the alpha branch, unless it was for a feature not slated for that branch. Then if needed in the upcoming release branch they backport it there. Then if it is needed in all the legacy branches, then backport it over to each one. That's somewhat of a hassle, but it was pretty easy compared to merging.

So we would sometimes have feature specific branches, when a feature would take a long time to develop. For example, when we are working on a new hardware platform, which might take 3-6 months before we go from initial prototype to going into production. So we would have a platform specific branch, so we don't pick up any potentially feature or build breaking changes coming from other teams and then go down the rabbit hole of investigating if this thing is broken because of the hardware or platform code, or if it was someone else's fault. But a lot of changes from other teams go into Trunk in 6 months or so. So at the end, we now need to merge the platform branch into Trunk. That would take about a week to merge and run our regression tests to pull off. Big pain.

But I don't think someone posting on the Unity forums asking about what are good source control systems is in this kind of environment. You've probably got a relatively small team all working off 1 branch. If you release a new version and then move on, and then later find out you need a quick hot fix for something, worst case you just check out another copy of the repo, roll it back to the revision you last released under, then add your hot fix. Then manually add the hot fix to the latest revision of your repo. That's why I was saying the branching advantages of Git are probably not that big of a deal for small teams or solo devs. I mean they can be helpful, but I haven't needed it. YMMV

 

Branching really sucks with svn as far as I'm aware.

"git submodule" for using dependent repositories.
git lfs for binaries.

Adding files is similar to svn - "git add -u" or "git add ." depending on what you're doing. You'll need to setup a proper .gitignore to ignore junk autmoatically, though, if you're using blanket addition statements.

Branching is the reason to use it, though. rebases and merges and all. And experimenting.

 

How can you not have dealt with branches? Bare minimum is a dev branch and production branch

 

This is how we have been running for a few years - master branch, development branch, and then a number of "feature" specific branches that get merged into development when ready. At points development is PR into master, with master being stable features only.

This way of working works great whether with 1 person or 100 people.

 

I was purely a hobbyist up until the past few years and none of my projects left the development state.

 

Congrats on making the jump to professional

 

I have used my own variant of gitflow workflow these last couple of years and it works very well.
Also very nice in devops that you can tag your commit with #666 were 666 is feature id. And when you commit it will autoconnect the commit with the feature (work item in devops). When deploying to production or a test enviroment it will display all features that will go out in that release.

edit: Word of advice. Be careful with cherry picking, it will create a new hash which breaks compare features as described above.

 

Hey,

Many thanks for the helpful input.

On the question of how big the team is that it's about. We are up to date in my company
6 programmers and 3 graphic artists. But mostly 2-3 programmers work together with 1-2 graphic artists on a project.

So far I've only had to do with git and git lfs, through Unity I found PlasticsSCM somewhere and it sounded interesting.

As far as I know, we don't want to set up our own server at the moment, but rather use a hosting service. I will do that again
discuss with my manager.

We are currently working with Collab, but that always leads to stupid situations because we cannot branch.
Here it was often said that the branching / merging with SVN was not so good. I will definitely take my time today
and understand the differences between git, mercurial and svn.

many thanks again to everyone

 

It sounds like you need git + git lfs, and a decent host. And then either learn command line really well (most powerful, highest learning curve) or get a good GUI (fastest to use, easiest to learn, more restricted what you can do)

For git GUI I recommend tortoisegit, for merging I recommend Meld (or just what comes with tortoisegit is fine)

Branching is best with git, it can be done with SVN but its not a great workflow

 

In 2019 where we was only to programmer we had try use Git + Git lfs and bitbucket for the GUI we used Sorcuetree because of many trouble with Git lfs and storage my boss decided that we switch to collab.

Now we are bigger i tell him we need branching.^^

What do you think about sourcetree?

 

Personally I find sourcetree awful compared to others, but with GUI its all about personal preferences. I suggest you try a range and find what works best for your team. That said, you can never go wrong with tortoisegit

 

thats sound like a good idea
tank you

 

While I agree you might not need the branching/merging of git (svn can do it too but it's awkward) the real deal is that SVN isn't as supported or widespread as git is. The tools are pretty limited and new clients just don't support it. I would consider moving off of it so that you could reap the benefits of git (I use gitflow all the time, even for personal projects) and the supporting tools. I get it's been working for you and that's great, but that's a slippery slope you're on where one day tools or integrations won't be available. Personally I wouldn't want to be in that position.

 

SourceTree is horrible and bloatware. If you're exclusively using GitHub then GitHub for Windows is fine. I personally use Fork which is light and does everything I need. There's also Kraken and a couple of other clients that are good. Or just plain git command line works too if that's your thing.

 

My personal choice and recommendation is git on GitHub (with whatever client you want, but not sourcetree). Repos have no limit (I haven't hit it) and private repos are free. On Github, you'll get warnings at 50MB on files and there's a hard limit on 100MB so things like lighting assets from a bake generally won't make it in (even with LFS). There's a Unity .gitignore you can use (even when making new repos) so it's easy to use. I just add in an extra couple of lines to ignore my assets except for my project so I don't drag in things from the store. If you're going with your own git server/hosting then you don't have to worry about that. The branching and merges are easy and on large teams for the past 10+ years I've never had conflicts. It's a nice system where you can split off a feature branch (I use a gitflow workflow) for say a new version of Unity, then abandon it if it all goes south or merge it into your mainline.

 

This is what we do basically. We have github + git lfs, and then we use a mixture of git commandline, the github standalone app (for simple pushes and pulling, branching out etc) and tortoisegit (for more advanced gui stuff that is difficult or impossible from github app)

Works great and works a treat with unity

 

I've found Git LFS to be tricky unless you set up your *.gitattributes exactly right (which generally means avoiding the unity ones you see posted as answers to how to set up git lfs for unity and really knowing how to configure those file types yourself).

When it works though it works. I've never used bitbucket, so I can't speak to that one, but I know GitHub integrates with the cloud tools well enough (I don't use the paid one, so I can't give you specifics, but I know a handful of people here are using that setup).

 

SVN used to be far more widespread, and a decade ago was the defacto source control standard for the software industry. It does what it does, and does it well, without trying to do anything more. Its real advantage is that it is very easy to understand how it works, very easy to set up your own private server with disk space being the only real hardware requirement (uses almost no CPU), and the only tools you need is the command line client.

 

Bitbucket + git is pretty much "it just works".

Originally the main reason for using bitbucket was that they offered free private repositories, while github didn't. Github was "make your project opensource or pay the hell up". And the cost was IIRC in ballpark for $25/month for selection of features that wasn't that great. That's is no longer the current situation, though.

I had impression that bitbucket was more geared towards supporting mercurial or svn, than git, although git was fine. I might be wrong about that.

I cannot comment on differences between git/mercurial though. Never used mercurial much aside from occasionally downloading a repo here and there.

Yes, it was, although I'd say 15 years ago and not "decade". And before SVN there was CVS, which IIRC(?) SVN replaced.

 

If you store pure code/text: git > svn any given day.
If you store a game project with all the source files, including binaries / source assets: svn > git any given day.

Git LFS is a bad joke keeps on going...

 

Rather Perforce > SVN > Git any given day
SVN at least has file-locking, since forever? And properly handles binary assets

I'm always curious why people use branches for games so much?
Personally, I never needed a "feature branch" while working on video games in 10 years. Yes, I know it's needed when working on some bigger piece of software that's gonna be ready in few months, like engine system or platform support.
Totally needed when working on live games, need to have development/release branches. But for the regular game?

I'm not saying that anything's wrong with the approaches described above. Just trying to add another perspective

Recently even Epic abandoned separate branches (like dev-rendering, dev-framework) and they submitting daily work directly to the main branch. It's more risk to mess something up, but much less work with merging changes.

Merging code from the feature branch is fine, but if I'd have to merge binary assets, I'd commit suicide.
While working on smaller features (up to a few weeks of work), I simply use Perforce shelves - a numbered changelist stored on the server, but not visible to other users of the branch (unless they would decide to). In some ways, it's easier to use than Git branches. It's because I don't even switch to another branch, I do daily sync all assets and code from other people. Fixing minor conflicts daily it's much easier than merging changes from many days.

Obviously, Perforce isn't suitable for anyone who wants a cloud repository, but... since this thread is already about sharing all the experiences... I'm adding it to the list here

 

Yeah I have some traumatic early experiences with perforce from years ago, so I generally don't like it (although I can use it if it is needed). But it has some advantages. At the same time perforce is (at least was?) more expensive to keep than SVN so we ended up using SVN for our projects (or later git when it's just mostly code) and used perforce when the corporate client had perforce.

 

This was for a Java project in Netbeans, but a customer wanted me to make some changes to a program we were already using "in production" (not really a "production" here but that's something else). git's branching was absolutely critical for that because I was making bugfixes to the "production" version while getting the new features up and running,, and I'm just one guy working on the program.

For my personal project in Unity I've just been using this.

 

Yeah... Perforce always gonna cost something if you have more than 15-18 people in the team. Yes, technically you're not limited to 5 developers on a free Perforce server
Smaller indie studios usually don't buy licenses for every person. Perforce doesn't care, they make money on corporations like NASA or IBM

 

To avoid breaking stable versions and to experiment without wrecking everything else.

 

I love branches, with branches we can always have a migration branch thats on one of the latest versions of unity. You have master which we use as production branch, bug fixes goes here. You have current dev branch. And then you have the feature branches. Nice and tidy.

 

What's wrong with SourceTree?

 

Sourcetree is incredibly prone to freezing and locking up. It can take hours to do file staging.