Discussion Making the Unity gitignore easier for students (at my school)

My sicko backstory
I'm Casey, a fourth year bachelor student at the HKU (Hogeschool Kunstacademie Utrecht) studying in Unity Development. Our school centers around doing game projects in small (indie-sized) teams of artists and learning by doing.

Every now and again, I help teams out with some feature or issue. 9 times out of 10, this issue is git commit conflicts. And 9 times out of 9, it is because of some "gotcha" that they didn't know about. Not every team has a developer, and if they do, this developer might not be comfortable with git yet, especially if they are a first- or second-year student.

I've seen many empires toppled, many projects loosing momentum because the whole team needed to stop what they were doing because Jim-Jo-So-And-So pushed a .DS_Store file they weren't supposed to. And I've had enough! I'm creating a master gitignore to request for becoming the main and ending these dumb git conflicts once and for all!

How to join the revolution?
I've created a pull request with the changes I think should be included in Unity's default gitignore. You may find it here: https://github.com/github/gitignore/pull/4231

Give it a thumbs up to show your support, share it with your Unity-friends, or offer suggestions in the PR to make it even better!

I've created this thread as a means for lighter discussion, that need not bog down the github comments. Any and all feedback is welcome! Remember to be kind to one another: we all want the same thing, which is a better gitignore by default.

 

In my book things like .DS_Store belong in your

.gitignore_global

, otherwise if you get a Linux or PC git repo from someone, you'll be sad.

Just remember that complex automation generally only takes you 99% of the way to the goal. Most attempts to go that last 1% introduce far more side effects than do good.

endymion:~ kdekker$ cat .gitignore_global

*~

.DS_Store

x.x

x.x.meta

Thumbs.db

Desktop.ini

.vs

.vsconfig

*.blend1*

*.blend2*

 

What's sad about that is that in 4 years of lessons and 2 years of being an active community member I have never heard about global gitignores. A quick read later and I agree, this should not be part of the standard gitignore, but on the other hand if global gitignores are so underground I still fear nobody is going to use them, so maybe they should be included?

That's fine, it doesn't have to be complex automation perse, but I would like it to cover all bases of what e.g. a team of artists and git-unaware programmers would deal with. <- editors note not even remotely claiming I fully understand git, but I get better every day ¯\_(ツ)_/¯

Even so I added in some edge cases e.g. the commits "Add miscellaneous ... files" since it doesn't seem like it could harm, but I'd love more discussion about that.

This is handled by the line

*.blend[0-9]*

and covers a seemingly infinite amount of tmp blender files (I've seen it go up to 5 in the past).

 

This really comes from git's origins in the Linux/Posix space.

Over there it is all "RTFM Noob!" most of the time.

But with Stack Overflow more and more people CAN read the manual, or at least enough to find stuff.

The only real defense for this stuff is to be constantly learning and looking stuff up. If you go a week without increasing your knowledge about *INSERT COMPLEX SOFTWARE HERE* in some substantial way, you're probably missing out.

Which brings me to this:

Admirable, but the other problem with that last 1% of failures is that if you zealously guard all that away, there still comes the day when it WILL fail or have an issue (all complex software does), and if you don't have at least week-to-week experience behind the scenes with complex software, you are just lost. That's a significant penalty to get 99.99% automation: you completely forget how to even fix anything, and even more perniciously you might not even NOTICE something went wrong, such as a botched merge in a remote feature branch that silently strikes out a bunch of mainline work.

 

At a university? May I please present an alternative perspective?

When you're at school is the perfect time to run into this stuff! The deadlines are the easiest most people will ever have in their life, and they're typically surrounded by others who are learning or people who are literally paid to assist. Yeah, it gets in the way of finishing the project, but the whole point of a uni project is to generate learning opportunities!

And, critically, problem solving this stuff is a fundamental skill that anyone working with technology will absolutely need as a part of being a competent professional.

With that in mind...

... the learning opportunity that you described, just here, is pure gold. Please do not take it away from anyone!

From your perspective, you're protecting them and their projects by keeping the gochas at bay, and I really do get that. But as both a learner, a teacher, and an employer my perspective is that they will have to deal with this stuff at some point, and I'd much rather do that in a learning environment than when dealing with a boss to keep happy, a deadline with money riding on it, and/or a client who could damage my reputation.

Dealing with this stuff is a fundamental skill in this industry, and students who haven't started developing it are not being adequately equipped by their educators.

 

Though I should follow up with this:

I've got nothing against updating the standard GitHub provided .gitignore file if there is universally useful stuff that's missing from it. That's helpful for everyone.

 

Oh yeah, @angrypenguin makes a really good point:

You will NEVER eliminate conflicts.

Nuisance conflicts are annoying but at first are indistinguishable from true conflicts that could genuinely end up in loss of work.

You have to be good enough to instantly isolate nuisance from actual and act appropriately.

It's not optional, and the larger the team, the more the conflicts.

You want a conflict a week to keep the doctor away, and as Angry points out, no better place to learn that Uni.

We were reviewing code in Discord today (7-person team, 6 eng and 1 artist) and there was a conflict. It was such a common and unimportant occurrence that the demoing teammate just said "Oh hang on, there's a conflict." and quietly went about resolving it without even another word while we watched. All of us just stopped talking for a minute or so while he want down the diffs, found the resolution and picked it. As his team lead I didn't even have to say a thing because we deal with this stuff all the time, my team is unafraid to fix stuff, and I'm confident they will fix it.

 

This is going kindof off the rails:

The only way they'll never get any conflicts is if we start ignoring these lines:

Code (CSharp):

1. *.unity
2. *.prefab
3. *.asset
4. *.mat

So that basis is covered.

But fair's fair: I shouldn't speak for anyone and I should ask some of my own teachers and peers what they would think of this argument.

In the end, that's my goal, figuring out the best way to do it is the journey. It's still a reality that people are dealing with .DS_Store conflicts (not just at my school if I should believe stack overflow). At least at my school, these conflicts regularly cause teams to lose momentum, sometimes redoing parts of a scene because they don't know how to deal with it, and this is fourth year artists I'm talking about! The conflicts are actively stopping them from learning more about creating game art in the process - maybe it's our school that should better prepare us for source control (we've had a total of 0 lessons about it) but the way these teams resolve them doesn't seem like the most productive lesson they could be learning.

As a good example of what I strive to fix, right now I keep seeing "UserSettings" in a lot of conflicts: this has been added to the gitignore in the past six months for the future generation, but is blocking progress for teams right now. Perhaps general OS files should remain gitignore_global, but I think at least it's been long enough to give "FMOD" and ".blendx" a spot in the limelight.

 

(And still this could go both ways for me, if maintainers say it's approved I'm not gonna complain.)

 

I mean the big problem is really that game dev schools doesn't put any effort into teaching version control and just assumes that people will figure it out. If you don't teach it properly, most artists will just think that this is an annoying programmer thing and that they could just be using Dropbox instead if it weren't for those damn nerds.

A good default .gitignore is nice for sure, and if people are sourcing it from that specific github repo, then improving it will help for them.


What you also need is a good tutorial for how to solve the DS_Store problem. Or more general - a file is in the repo, and you want to have it not be in the repo. So now you have to both add it to the .gitignore and delete it, and make sure that nobody selects "use mine" when they get a conflict with the deletion, because then you're back where you started

 

Today I learned about the existence of .gitignore_global! That'll be handy...

 

This. If you tell anyone (artist or otherwise) that something is stupid and you "just have to suffer with it," they won't put the effort in to really excel.

We have an enormous cadre of extremely talented artists at our company and we expect and support them all to be First Class Citizens in our Unity projects: edit, commit, merge, etc.

EVERYBODY who touches the repositories receives ongoing training and support.

We all work in a constructive environment of knowledge and support and training, where every individual is encouraged to rise to the highest of their abilities, and everybody knows they can seek help if they ever get in over their heads.

Source control is just software. Yes it's complex. Yes it can get messed up. Yes even I can do stuff in git that leaves me baffled. But its use is mandatory.

The process works fantastically well. I wouldn't work any other way.

 

I see that a fair bit with the undergraduates I work with -- very much this situation:

 

Even then they need a quick lesson in “what’s safe to ignore” or they’ll actually start ignoring scenes (I’ve literally had the question once “if they cause so much problems can’t you just remove it?”) - so basically they need to learn the right google prompt.

Expect my resume in half a years time :3

 

Ah, right. I honestly thought that was an exaggerated example.

In that case, either the tool isn't being taught properly, or the lessons aren't sinking in. Either way the school should be improving things, because the stuff you've raised really shouldn't be considered advanced use or contingency, it's fundamental usage stuff.

Including, people should be broadly familiar with, or be equipped to look up, the file types they work with. If they can't then they're doomed to Cargo Cult approaches to things. Asking if they can ignore .scene files sounds silly, but is a fair question the first time. Instead of answering it, I'd walk the students through how to figure it out for themselves - another golden learning opportunity.

That said, from memory, DS_store probably can get ignored for everyone with no downsides.

And Git certainly has its foibles, not the least of which is that there's no one clear path for beginners. At one of my previous jobs, my "How to perform common tasks in Git" document was the single most used document in the business. If your school doesn't have one, perhaps you could write it?

 

So true unfortunately. git is a harsh mistress, alas, but I can think of no way to improve it.

I have my own mental book of these kinda runbook "sequences" in brain... I really ought to write them down sort of like a tree structure:

- generally do this
---> if this happens you're good
---> if XXX happens then generally try this...

etc

 

Based on the discussions here I've updated the PR with newfound knowledge (for which I am extremely grateful!)

Learning about global gitignore really caught me with my pants down, but if it's part of the design than that's really all there is to say. Also had to come to terms with our education being even worse at the source control part of learning than I realized, so I'll be refocusing my efforts on them more than the gitignore now. That doesn't mean it's dead btw, just rebranded to be more focused on adding some integration ignores to it, more akin to, in their own words:

 

You'll be happy to learn that it doesn't just happen in universities. At a multi-billion dollar corp we had one team check in a 100+ megabyte video file. It wasn't even the final video which would have been bad enough.

 

What? Don't be unfair on yourself.

Nobody knows everything, and that's an unrealistic expectation to hold. What's far more important is that you put yourself in a position to learn about stuff, and have taken things on board as they've come up. These are good things.

And your school isn't the only one to do poorly on the version control front. It's a difficult topic to cover well, especially to a broad range of students. I'm tempted to suggest solutions, but this comes to mind. Though also, this is such a thoroughly common topic that I kind of feel like writing a new Git guide if/when I have time and putting it online.

 

I fully expect to learn something new every single time I do any significant amount of coding.

Just today I noticed that the rigidbodies driving the little green eyeballs on my exploding firecracker dude were not marked continuous collision, and because they're so small they would sometimes fall through the ground after I blew him up.

 

I once wrote an introductory tutorial for a fellow artist.
If you don't mind it being in Chinese, you can use it as a reference.
KumoKyaku.github.io/git的快速入门教程.md at develop · KumoKyaku/KumoKyaku.github.io

 

Well I don't mind perse, but unfortunately it's not for me :') thanks though! git is in dire need of a better learning curve if you ask me.

 

Lesson learned: don't say you're gonna remain just as active right before crunch time.

I've been asking myself in the back of my mind how to bring these git issues my school's having more to the forefront and then I thought "wait a minute, there's a thread of teachers I can pull from".

I would be really interested to learn your perspective of what's needed to bring more awareness to this! It's easy for me to say "our school's at fault" but it's certainly not from disinterest on our teachers behalf, so I'd like to learn more how I could best approach (one of) them about this topic in an actionable way.

 

Au contraire, in my experience. The academic types (and I'm painting with a VERY wide brush here!) don't see the value of most of the critical parts of actually earning a living with software engineering: source control is just one example. Another is the idea of a dirty-rotten hack that expedites shipping the game out.

Therefore they hand-wave and pooh-pooh these concepts, to the detriment of their pupils.

 

Nah we’re pretty lucky with ours. There’s one like that but the others all truly care.

 

Is there a dedicated lecture and a tutorial just on version control? That's where I'd start.

First up, make it the primary message for a while, instead of a separate thing that gets in the way of the code / art / etc which I'm really trying to work on. As long as it's seen as a distraction or a nuisance people won't engage with really learning it.

Second, this will get the teachers thinki g about what needs to be known and practiced. If I was going to teach 2 x 1 hour sessions on VC, what would I cover? What would I get students to practice?

Third, make sure to get students to understand that while VC is an overhead at first, it's way better than the alternative. My first software project in a team involved manual merges at the end of each day. The whole team stopped for an hour and gathered around one PC. If you think about the productivity hit that has (around 15% of work time lost) it's madness. For the next project we used VC. There were a couple of weeks of issues as we learned the ropes, but from day 2 it saved time. And everyone, except a new fellow who hadn't experienced the old way, loved it. We ran into the same teething issues everyone does, but we weren't comparing them to nothing, we were comparing them to the reality of a fully manual merge. So, maybe, get students to experience the problems VS solves before throwing them in?

 

It's even worse for aerospace contractors. No team can know what the other team is working on so there is an integration team, or basically one point guy who goes around with a bunch of secure hard drives, gathering up all the code from each team for a given unit of work.

This integration team takes all the source and builds and integrates it all in a vacuum at their lab.

When there are issues they go back to the involved teams and ask them what needs to change (in the integrator's version of the code!) to get it to build at the test lab.

Remember, nobody else can see what the integration team can see.

Crazy. This was 2006... I wonder if it is any better today.

And this is mission critical code: flight controls, weapon controls, environmental systems, radar, threat, nav, comm, etc.