Source control confusion

I am developing a game for android. That means I had to click the Switch Platform on the build settings, so the assets got reimported like usual.

Now the question comes when I wanna use source control.

I created a private repo on github with the recommended .gitignore, cloned that blank repo into my local drive and put all my project files there, staged, commited and pushed with sourcetree.

Deleted that entire repo folder from my local drive and cloned it again to simulate a fresh install on another hard drive, just to see what it would be like.

Ok, added that newly cloned folder to Unity Hub and opened the project, as expected it reimports missing libraries as the Library folder is ignored as specified on the .gitignore.

One thing I see is that my cloned project got the good old Window Layout error at startup which is solved by clicking Quit and opening the project again, then I am presented with the Unity's default layout, no issue here as I can redo my layout, it is also defaulted to build for Windows, so I change that to Android, which causes Unity to reimport all needed assets for the target platform.

Now let's say I add a new developer on my team, he would clone it like I did, he would need to do all that reimporting of files all again right?

I don't know what is it but I am kinda unconfortable with that, like its some unecessary stuff which could cause conflicts in the future?

 

That's it, that's the magic!

This is EXTREMELY smart. This is the step a lot of people miss... you have just proved to yourself that when you add a new developer, his system will have everything it needs to build.

Conflicts are conflicts, but the whole point of distributed source control (such as git) is that as long as you have committed your changes, you can leisurely resolve conflicts as you are able.

Workflow should be:

- make changes, test, iterate
- the moment the smallest amount of measurable forward progress happens (even if it is just notes!), commit

When you pull, git will merge to the extent possible, which could require a new commit of the merge, or not, if it is a fast-forward merge.

Either way, as long as you commit and push regularly, NEVER force push, your work will be up on github.

If you cannot resolve a conflict and thus cannot push, the safest course is to branch afresh and push that. Then if the OTHER guy pulls, you can have him do the conflict resolution step.

Here are some more notes:

Personally I use git because it is free and there are tons of tutorials out there to help you set it up.

Here's 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

 

But, doesn't it seem like an uncessessary step? I don't plan on building for windows so in the repo all files should be already imported for android, which I guess they are but on a "fresh" project unity thinks its building for windows so unity reimports them, so the guy cloning my repo for the first time would import the assets twice because our target build is android...

So from what I understand, source control is for backing up and being able to revert changes in a project while not being tied locally to your machine in case anything goes wrong.

What I understood also is that files that can be generated by Unity itself, be it on the startup or downloading from the asset store/importing packages(if not modified by you), should be kept out of source control.
Other files like your own source files, 3rd party assets from the asset store that you modified(only if you modified them), models, sounds and other binary files should be commited to the repo because they can't be downloaded/generated anywhere else?

Am I correct?

 

You're way overthinking it.

All "import" does is a transparent-to-you step of pulling in the assets and doing some magical preparation for them to be built into the game: renaming the files internally, assigning GUIDs, injecting other features of the importer, etc.

It's gonna be really hard for your teammates to build your project without all the files.

Rule of thumb:

100% of files inside of

Assets

,

ProjectSettings

and

Packages

folders need to be committed.

All other files should NOT be committed, unless they are your work notes files and you want them committed.

 

Yeah you are right. So the packages folder doesn't refer to asset store packages, but to critical packages, right?

I am already including all 3 folders you mentioned, I am using the default unity gitignore from github by the way.

 

The fixing layouts and setting build settings after getting a new copy of the repo is something that happens just once, and doesn't take long. The reason is the files which cover this stuff aren't under source control. I believe the layout isn't even stored within the project folder.

You don't necessarily want that stuff under source control anyway. For example, lets say you've got one developer working on Windows standalone specific assets. You've got another developer working on mobile specific touch controls for the android build. Do you really want the build platform flipping back and forth for everyone anytime either of them checks in their code? They may also have different custom layouts that are necessary for the specific workflow for what they are doing. Do you want to force everyone on the same layout regardless of what part of the project they are working on?

 

The packages folder generally only contains one file, the manifest.json, which lists all the packages in use.

This tells the Unity Package Mangler how to go get all the other stuff.

This is an unfortunate design choice because it prevents you from working without being online, but alas there you have it. In other words, I couldn't give you the project on a thumb drive and send you somewhere there is no internet, because you would be unable to reconstruct the actual payload of the packages and your project would remain broken until you could.

 

The packages folder isn't for asset store assets. It is for what are basically extensions of the Editor from Unity. It is confusing because Unity has also moved downloading your Asset Store purchases also into the Package Manager.

 

Yeah I'm not a fan of this either. It puts a dependency on the Unity company that they do not ever remove old packages from whatever package server they are using, for as long as you are supporting your game.

 

That's gonna be the first thing that goes dark and then we'll all be proper #%$@#$ed.

 

Thanks to both of you, yes it is indeed confusing if you look at the packages folder and the package manager, one would think everything you get from there goes into that folder.

So i guess if i follow these guidelines there is nothing that i need to fear.

 

Is it normal that in the start I really forget to commit and then at the end of the day I have a bazillion changes to commit to the repository, how do you manage that?

 

Yeah, it's normal... it's a habit thing. Over time you'll get better at it. As I posted above, I commit constantly, even if it's just a small change that I know is gonna at least move the ball towards completion.

In fact, sometimes when I get started, I rough out with comments everything I want to do, and commit that, then go back in an actually write the functions.

Another trick is to put a one-hour timer on your phone and when it rings, start selecting related stuff to commit as a unit of work. And every time you get ANYTHING interesting working, that's a time to commit.

I dunno if you saw the example link I posted above:

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

 

Yup. I was pretty much the same when I first started using Git as well, and it's a habit you eventually grow out of.
At the beginning, I also completely forgot about Git's ability to group and commit specific changes, instead of committing everything altogether.

If you're using the command line, remember to use

git add <file-name>

for all the related changes you want to group together before

git commit

'ing.

Most editors (like Visual Studio and VSCode) come with Git integration and have their own GUIs for managing Git commands. The equivalent of adding/committing for that is usually highlighting all the related changes you want to group in a list, then right-clicking your highlighted items and selecting something along the lines of "stage changes".

Lastly, here's something that may come in handy for common troubleshooting issues with Git:
https://dangitgit.com/en

While Git is powerful, a lot of its command names can sometimes be confusing. Eventually you're going to commit something by accident and want to undo that, and let me tell you, if I had a hundred guesses as to what the command to undo the last commit would be, I would not have guessed

git reset --soft HEAD~1

.