I’m still pretty new to version control. I’ve recently started using git and I’m loving the power it gives me. But I’m struggling on the practical differences between a fork and a branch. I get the mechanical differences, but I’m struggling to pick the actual use cases for each type of split. Anyone have any experience and enlightenment? Any tips for working on this sort of thing in the Unity environment would be helpful.
Use case background: I’m a solo developer with complete control over my project. I’m about to implement networking features, which may or may not work. Its also likely to go through several stages of breaking the entire game while its getting fixed. At the same time I need to keep the main repo live for doing bug fixes and to allow continued builds.
The obvious solution would be a branch or a fork. I’m not familiar enough with the system to know the implications of doing things each way.
Any advice will be appreciated. Failing that I will just back the whole thing up and do stuff and report back on what happens.
I would make a branch, at least in my usage of Mercurial.
When you commit network-specific code, be sure you are synced to that branch and commit to that network branch.
When you are making mainline improvements to your game, exit Unity, resync to default, and work that way.
If you stall out on your network branch, you can always continue on default and your game remains solid.
If you put some new features in default and want to bring them to network, resync to network and merge default into network, and commit to network.
I’m doing this with Android TV versions of my mobile games: each project that I am bringing over has a “tv” branch and it contains only the specific code and scenes and configuration tweaks that will use the controller. The mainline development continues in default, and when I work on “tv,” I just merge the latest default improvements into tv, keeping it up to date.
Now I’m using Mercurial, so I believe you want to change all instances of the word “default” above into “master” but I don’t have enough seat time in git to confidently state this as a fact.
My understanding is that the difference between forking and branching are mostly about permissions. You branch in the case that you have control over what gets merged back into the master branch, and you fork when you’d otherwise not be able to do anything, as you aren’t an official collaborator on the master branch.
As the person in solitary control of the project, a fork would only increase the difficulty of merging things back together later- it wouldn’t make it at all impossible, just a few extra clicks and/or lines of code, but more difficult none-the-less. The only case that I can think of it being particularly useful when working on your own is if you wanted to go two entirely different directions for a project that will be impractical to ever merge together (like a Linux version versus a Windows version, perhaps?), otherwise branching works just fine.
If you were working in a team though, you could make it so that the lead developers could push/pull and merge whatever they wanted (or just you), while the rest could only fork to make their adjustments and then make pull requests for you to look over and approve when they finished what they needed to do. It’s to solve the “too many cooks in the kitchen” dilemma.
Anyways, I’ve never actually used Git beyond as a personal backup system (so that I’m not screwed if my computer blows up), so my knowledge of the differences is largely academic- and likely a little mis-remembered.
I always thought a fork was when you wanted to take an existing project and start a new ‘version’ of the project.
Like say you went onto my github for spacepuppy framework, and you wanted to expand on the project for your own use or to make your own flavour for sharing. You’d fork my project and make your changes and use it.
Where as if I was doing some changes to my project, and I wanted to quarantine it from the main branch, so that it doesn’t taint the main branch until I’m done with it and then merge it back in.
Yeah, I really look at using forks for personal projects as a kind of “protection through obfuscation” situation- the fact that it makes it a little more difficult / more work to merge back into the main project is nice only in that it makes it harder for you to do something stupid on accident. Beyond that though, it’s mostly just semantics.
The new “version” of existing projects is indeed one use (for when you have no association with the project in question), but it’s also used IIRC as a kind of control mechanism for teams that have multiple levels of experience and responsibility, so that the “B team” has to have their changes approved and merged into the master branch by someone who actually knows what they’re doing. Worth noting that even if you have no association with the project, you can usually “request pull” for additions you’ve made and have them merged into the project, assuming they were changes worth having. I imagine that would make you feel all warm and fuzzy inside ^_^.
Wow. This is easier then I thought. Made the branch. Made some changes. Clicked back to the master branch and Unity detects the change and reloads the project for me. I like it.
I believe I am now officially converted to version control.
Yes, I think this is spot-on. If I have Game X (lets say a turn-based strategy game) and the development reaches a point where I see it can be skinned into two similar yet fundamentally-different genres, say fantasy (Fire Emblem) and modern warfare (Advanced Warfare), I think that would be when you would fork versus branch.
And the “control” issue that Lysander brought up would also be a demarcation point, especially if I wanted to use an existing project to “seed” my own new project, and did not have any intention of giving back to the original project, such as taking a Unity “complete project” or “demo” and then forking it into your own product.