You see, the word ‘forking’ sounds a little like ‘fucking’ so we laugh. Jokes. Ah. So. All this Git stuff is great and all, but after setting up one project to integrate really well with Git, adding submodules, branches, etc, you don’t really want to do it all over again for each project. Luckily, as with all problems in the first paragraph of these posts, Git is the answer. Bitbucket, Github, and other repo hosts offer a feature called ‘Forking’, which is really just copying a repo in a fancy way. It’s a fancy way because each copied repo (fork) maintains a connection to the original repo, so if you update the original you can sync the changes into each forked project (and vice versa). A little like a branch, although the repos themselves have no knowledge of the other forks. Continue reading Unity + Git, Friends Forever – Pt 5 : Forking Git!
Any developer or team ends up building a base of code or assets that they reuse in multiple projects. Your team (using Git and a workflow like I outlined in the last few posts) has made new stuff so quickly you don’t know what to do with it. While Unity makes it easy to drag and drop files between projects, it has no built in ability to manage these reused frameworks. As these frameworks become bigger or more important, you need to start managing changes to them more robustly. If you fix a bug while working on one project, your other projects using the same code should get fixed too. You should be able to revert to a past version of a framework without untangling it from the rest of your project. What might help with this? Why, Git, of course! By using Git’s submodules you can get all the benefits of a Git repository plus the ability to add that repo to any project.
Submodules aren’t perfect. They’re rather fragile little things and unlike most other Git operations, if you trip-up you often have to start over. But not to worry! Follow these simple steps and you’ll be sharing assets so much you won’t know what to do with them. As before, I’ll detail the process in both SourceTree and with the command line.
OK, so you know how to set up your Git repo (Part 1), and you know how to use it (Part 2). This
final part will go over the workflow I use with my Unity projects & how to collaborate with other members of your team. Part 4 will show how to reuse code or other frameworks, and part 5 how to quickly start a new project with all your favourite settings & packages already installed.
This is part two of a three part guide to using Git with Unity. Part one deals with setting up Git and Unity to work together, while part three will detail a workflow that works well with Unity projects in particular. This part is a guide to the essential Git functions you need to know to use it. It will most help those new to Git, but anyone can use this part as a Git cheat-sheet, or as an intro to SourceTree or the command line.
So…what can you actually do with this Git thing?
Continue reading Unity + Git, Friends Forever – Pt 2 : The Essentials
I recently wrote a quick post about how I use Git submodules to manage my code/asset packages in Unity. While writing it I realised how difficult just getting to that stage with version control can be.
We’ve all heard how useful this version control thing is. If you work in a team larger than 2-3, you need it to manage changes to the project. If you don’t, you need it to store backups and history. It lets you reuse code and keep it updated easily. It saves my ass daily (when my laptop died suddenly last week, it took longer to find monitor cables than it did to get my project up and running on another computer). It’ll save your ass daily too.
So, here’s the first a multi-part, step by step guide on how I use Unity with Git on OSX. Yes, there are other methods. Yes, there are other platforms. But I use Git like this.
So Robert Yang posted a decent guide on how to ‘sub-project’ your Unity projects so they can share a common code-base easily. This does what it needs to do pretty well, you can easily add to and maintain your own framework, and build individual games on top of it. This, as he warns, comes with some complications. You have to juggle different build/player/editor/project settings, each game’s /Resources folder will be included with every build, and you need to manage an ever-growing script base. I manage my shared code a different way, though the magic of Git submodules.
One of my current projects, needed the ability to record player input, then play it back on an object. This is something I’ve had to do several times already. In Muckraker it was how you could ‘film’ something. Rather than record all the changing variables on an object/character (position, rotation, whether they are firing…) you can in most cases just record what the player does. When you play back this input, the object will do the same things and act the same way. (keep in mind that external inputs, like physics, can make the object drift off course after a while, but this can usually be minimised). Even so, keeping track of inputs and playing stuff back without ‘live’ input getting in the way can be a headache.