Connecting Unity to Git, and automatically locking files

Hello friends

I am using Bitbucket for my project, and I'm wondering if there's a way to build git tools into Unity. (I know there's a github tool, but I'm looking for generic git).

The reason this would be cool to have is to implement file locking. Basically, my world is split into chunks. It would be very cool to allow developers to essentially say "I'm editing this chunk", which would cause Unity to tell git to lock specific files.

Any thoughts?
Josh

EDIT: Whelp, looks like Bitbucket doesn't support file locking. Oh, well, still interested I suppose.

 

By its design git cannot support locking. Every repository in git is a full copy and it cannot know about any other copies except the one you cloned it from (origin), and it can even forget that one if you want.

Having said that, git is AWESOME for working in Unity. Just be sure to go to ProjectSettings->Editor and enable FORCE TEXT for asset serialization, as well as Visible Meta files. Then get a .gitignore for Unity and you're all set to go.

You do not need to check in any of the csproj/sln/userprefs noisy crapola that VS/Mono needs. All of that is regenerated by Unity anyway whenever a file is added removed. And you don't need to check in Library or Temp.

I also recommend you do NOT put Assets/ProjectSettings at the root of your project but rather one directory down. This lets you stick other stuff in the root of the project more easily. I use this .gitignore to start:

Code (csharp):

1.  
2. Library/
3. Temp/
4. Obj/
5. Build/
6.  
7. # Autogenerated VS/MD solution and project files
8. *.csproj
9. *.unityproj
10. *.sln
11. *.suo
12. *.tmp
13. *.user
14. *.userprefs
15. *.pidb
16. *.booproj
17.  
18. # Unity3D generated meta files
19. *.pidb.meta
20.  
21. # Unity3D Generated File On Crash Reports
22. sysinfo.txt
23.  
24. # macintosh crap
25. .DS_Store
26. .DSStore
27.  

 

You might look into Microsoft Team foundation version control system. I haven't used it personally (I use them, but I do the git repo for myself). The Team foundation version control system is suppose to support some sort of locking I believe if I remember it correctly. (Don't quote me, but I'm pretty sure I saw something about this)

The repo service is nice because I can commit and push straight inside visual studios, making it fairly easy to maintain.

https://docs.microsoft.com/en-us/vsts/tfvc/overview?view=vsts

I had a quick look. It mentions something about checking out files which lock them, so might be worth a look.

 

I want to +1 what @Kurt-Dekker said.

We use git, it's great, and if you have unity in full text mode file merges are super easy (for the most part).

As for the file locking thing. Technically it's not a git thing. The idea is as Kurt described, you have a distributed repository.

With that said, people have tacked on the ability in various methods. Usually by setting up push permissions on a file/directory level and using git tracking to track a 'remote' repositories permission settings and flag the local repository based on it. This is usually a feature not of git in and of itself, and is usually respective to the git repo you're using.

Note... since this is so. You don't need to use something like bitbucket to share your repo. For example, we self host our repo internally, and anyone remote from the server (not on the LAN that where I have the server located) can VPN in to access it as a remote repo. If you do this, you can then layer whatever features on top of it that you'd like.

As for unity integration in and of itself. Honestly you could probably write a few editor scripts to handle this. Probably not that hard honestly. You just gotta check for when a file is edited (check the local repo for diff information, or even unity might have a hook for when a file becomes 'dirty') and send the lock request to the remote repo and mark the file readonly on the local filesystem.

I just tested, if you edit a scene or anything marked readonly. It just doesn't save... it keeps on trucking along. You might want to just add a 'icon' editor to any files marked readonly so that it shows a little 'lock' icon next to it in the editor.

...

Note at @Brathnann's suggestion.

We also used Team Foundation Server for a while before migrating to Git. At first we used TFS because the GUI wrappers for Git back then just weren't 'artist friendly' (they really relied on you having advanced skills like a programmer would have, or were terminal based).

It was serviceable. Though honestly in terms of Unity projects... it was sort of annoying to work with.

Now that tools like SourceTree are so user friendly, we've finally migrated to Git. It srsly is SO NICE compared to TFS on so many levels.

I won't like if you asked me 10 years ago about git, I spat on it. I hated the damn thing because it was so NOT user friendly. Working on teams with people of disparate skill levels made git a god damn nightmare. Sure, on a loan project where all you had was your self to blame for stuff it was fine. But on teams it was just a god damn headache (don't get me started on the last company I worked at who tried taking a 20 year long team of Microsoft developers and throwing them into git all blind. I showed up as the new guy and the only person in the office with git skills. Holy hell, every wrong thing that happened was "my fault" because I was the only one who knew it).

But honestly... with these newer modern tools. I can say git is finally at a user friendly enough level that as long as you have one skilled programmer on your team, all your no tech members can easily get by with tools like SourceTree (or equivalent guis).

Note - SourceTree though built for Atlassian/Bitbucket doesn't require bitbucket. You can connect to any old git repo. It's how we use it and I connect to our private repo on my private server all the time. I just really like the UX for it, and my artist/partner understands it (well enough).

 

Adding to what @lordofduct said, the best solution we had for file locking was to go buy some rubber ducks, one for each "main-ish" scene in the project (you shouldn't have that many), and write the name of the scene on that duck.

When someone wants to edit that scene, they must first obtain the rubber duck for that scene and place it prominently on top of their monitor while they are working on the scene.

If you get different-colored rubber ducks it can make it even easier to see who has what.

It doesn't (obviously) scale out to using something like git-flow or multiple people in different offices.

But it's good enough if coupled with some strict team discipline. It really encourages you to experiment a lot in scenes to find "just the right thing" to do, then back it all out and reapply your changes all at once to be nice and clean, minimizing duck lock time.

And if there is a conflict on merge, whoever had the duck gets to say "Take Mine" and the non-duck people can suck it and recreate their scene changes to remind themselves to always "Obtain the duck first!"

If you want to go high-tech duck, then share a google spreadsheet with lines for each scene and you write your name in the "I AM WORKING ON THIS SCENE" column and then have another column saying "TELL ME WHEN YOU'RE DONE" and put your name in that scene when you find someone working in your scene.