I use Github Desktop. I like Github Desktop. It is, for the most part, easy to use and the best way to keep my code safe during a project, to have the luxury of time travel when I mess up and a good way to collaborate. The downside is that when things inevitably go wrong I’m not really all that sure what I’m doing. A whole lot of Googling around and reading angry half-baked replies in forums helps me to draw up some command line statements to try out, but that can sometimes make things worse. Recently, my artist collaborator and I had a few file conflicts -well, a few thousand actually. We’re using Unity, too, so when there are conflicts with Scenes it’s not just a friendly warning in an app – your scene doesn’t open any more. Hidden inside the scene file is some newly added metadata to point out the areas of conflict. Annnnd, well, I’m not really sure how you’re supposed to deal with them. I’m working on that, but that’s not the point of this post.

As I hacked my way around, trying random things to try to get the old files back so that I could just merge them manually (why is this so hard to do?!) I made things worse. Then, I made things even more worse. Apparently, reverting changes from a few days ago then reverting changes again can lead to total disaster. My project was, at one stage, missing a lot of files, missing a week of work and riddled with conflicts.

So, it was time to head into the command line. I Googled again and read about something called a hard reset and a soft reset. As I understood it, a reset is supposed to revert back the repo to a previous state, but the soft reset didn’t put back the missing files I’d lost along the way (don’t ask me how- I have literally no idea!) so I had a reverted project with a bunch of files missing. I’d tried a soft reset, but it only seemed to make things worse:

$ git reset --soft d6948bd

There’s also the hard reset, but I was too scared of the prospect of a hard reset because you can’t revert it once it’s done and apparently all commits after the one you revert to, will be lost.

Then I discovered a savior.. a way to ‘rewind’ the repo and copy the rewound version over onto a new branch. This is some awesome stuff. You give it the ID of the commit you want to go back to, and a name for the new branch, and it takes care of it. There, on the new branch is a nice fully repaired reverted version of your project:

So, that’s

git checkout -b

followed by the name you want to give the new restored branch, followed by the ID of the commit you’re going back to. You can find the ID in Github Desktop by going into the History tab, picking a commit on the left and then have a look for a symbol that looks like a UFO with some hex next to it like this:

String it all together to look something like this:

$ git checkout -b unborked-project-branch d6948bd

And you got yourself a shiny new branch with a repaired project in it! I mean, yes, you may lose a bit of work from commits prior to it BUT it’s a way to recover a totally borked project and you can then maybe go back and manually merge updates by picking and choosing from the broken repo on the main branch.

The way I finished this up was to copy the files from the repaired branch onto my hard drive and backed them up into a copy of the project. Then I switched back to the main branch in Github Desktop and then copied the files over in File Explorer from the repaired branch overwriting files in the broken branch. Once that was finished, I opened up the project in Unity to make sure it still worked (it did) and made a new commit in Desktop to upload the working version of the project.

YES it’s a messy mess, but do I care? No. It saved my project from the jaws of a GIT disaster. Albeit one that I made myself *sigh* – it still worked, so maybe you’ll need this one day too?