Question About projects backup, team workflow and github

Hi!
Our team of 5 enthusiastic people has been working for 1.5 years. We've always shared files via Google Drive, and I've backed up (zip) there as well.
But there is a problem - it's inconvenient, it doesn't sync, it's hard to track versions there and there are no comments. To my shame I only recently discovered git&hub and I found it to be a convenient system to work with.
However, github doesn't support large projects (our unity project weighs 12gb), so I can't work in a unity project and at the end of each day push the project to the server, or my artists do their stuff and we all sync our repo

So I have a few questions for the advanced developers out there
1) What do you use to share files with artists? Maybe there is an analog of GitHub with the same user-friendly system, but supporting exchange of large files?
2) GitHub for me as a programmer is a portfolio. I know that there is a git list of exceptions, but can I do the opposite - so that only my .cs scripts are sent to github? Do you separate your project into your code and your artwork?
3) What do you use for backup large projects?

4) Mini follow-up question - what would you recommend for using Git? Github desktop? Or maybe some terminal for windows?

 

There's a business decision about how much source art you put directly into the repo.

There may also be some benefit to using git LFS

But you still need somewhere to park that 12gb, which is beyond most hosting services.

You could get a raspberry pi and some NAS and make your own git server.

Or perhaps submodules or even subtrees can help you.

------------------

PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

https://forum.unity.com/threads/prefab-links-keep-getting-dumped-on-git-pull.646600/#post-7142306

I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.

Here is how I use git in one of my games, Jetpack Kurt:

https://forum.unity.com/threads/2-steps-backwards.965048/#post-6282497

Using fine-grained source control as you work to refine your engineering:

https://forum.unity.com/threads/whe...grammer-example-in-text.1048739/#post-6783740

Share/Sharing source code between projects:

https://forum.unity.com/threads/your-techniques-to-share-code-between-projects.575959/#post-3835837

Setting up an appropriate .gitignore file for Unity3D:

https://forum.unity.com/threads/removing-il2cpp_cache-from-project.1084607/#post-6997067

Generally the ONLY folders you should ever source control are:

Assets/
ProjectSettings/
Packages/

NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)

Setting git up with Unity (includes above .gitignore concepts):

https://thoughtbot.com/blog/how-to-git-with-unity

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It's simply ridiculous not to back up.

If you plan on joining the software industry, you will be required and expected to know how to use source control.

"Use source control or you will be really sad sooner or later." - StarManta on the Unity3D forum boards

 

Artist source files would normally not be saved in the project, only exported assets (eg FBX) should be in the unity project and under source control. However since Unity supports blender files natively you may decide to have those in your Assets tree but then artists should not create „copies“ or „versions“ of their own by changing filenames.

Either way, artist source files should be frequently backed up one way or another. But they wouldn‘t normally be under source control because they tend to be huge, are typically edited only by one artist (no collaborative edits) and some formats are binary.

A Unity project should be under source control in its entirety, excluding the common .gitignore exclusions like Library folder. You cannot simply exclude some file types that are under the Assets tree without risking serious issues with the project such as losing assigned references or worse.

git LFS is pretty much required for a project this size, and hosting it on a server of your own (or cloud service but I tend to think that would inflate costs).
Alternatively you could look into Plastic (I think Unity owns that now?) or Perforce/Helix.

SourceTree is a decent alternative for Github Desktop.

 

This is one of the best answers I've seen on the unity forum!
Many of the solutions would be unnecessarily complicated for me, so I'm thinking of doing it this way:
I will create separate repositories for each artist (if github allows its weight), where they will send their graphics.
I'll backup my Unity project to an archive (since the size doesn't allow me to do otherwise, in case something happens to my computer).
I will also have to customize gitignore to include only C# code from the project I'm writing, and not to include assemblies, graphics, prefabs and other stuff (for my "portfolio"). Or maybe I should create a separate repository where I can clone code from my project (doesn't seem very convenient).

The only questions I'd like to ask a professional is, in case of code on github, should I create one repository connected to my project folder (as I mentioned above). Or should I create separate repositories for each solution (e.g. I wrote my gravity field for particles and array shuffler)

 

Glad you like the comment, but I really gotta call this out:

and then you proceed to list one of the most complicated ways I have ever heard of source-controlling stuff.

Everything about using a new tool, in this case git coupled with potential remote hosting locations, will require you to learn new stuff.

I highly recommend you operate in the simplest fashion first: make a single repo, commit ALL your work to it, then purchase the LFS add-on for github and push it up.

Alternately, purchase an enterprise license for $20/mo, add the LFS on and go. Give yourself a six-month trial window, which will be plenty of time to learn git and get a feel for what you're dealing with.

After that, decide if you want to cut back, decide if you can make do without massive binaries in your project, etc., and then change course appropriately.

But in all cases recognize that the cost of $25 x 6 is still only $150, and ask yourself how annoyed you would be if all of you and your friends lost ALL of your work because something went wrong with your complicated proposal above.

See the paragraph at the bottom of my post above. It's just simple basic low-cost economics. Choose accordingly.

 

Agreed!

I already said that his is highly problematic. NO ONE EVER deconstructed a team-driven Unity project into separate asset files and successfully recombined the result to a working project and lived to tell the tale.

You should look into Package Manager packages, they enable you to create modular code and assets that can be imported to other projects. You normally have a separate repository for each package. In theory you could create a large number of packages each containing small parts of the project but managing the dependencies between packages can eventually become painful.