Every Unreal project you make this year is one crash, one bad merge or one re-imaged college PC away from being gone. This is the hour that fixes that — set up GitHub properly, then prove it works by breaking something on purpose and getting it back.
Saving overwrites. It replaces the good version with the current version, and the current version is sometimes worse. Version control keeps every version you ever saved, forever, with a note about what changed — and lets you walk back to any of them.
Roughly. Every year, on this course, someone loses weeks of work. Every single time it was avoidable.
What it costs you at the end of a session. That's the whole price.
Every commit stays. You can open the project as it was three weeks ago, on a Tuesday.
Unreal crashes mid-save. The .umap is now zero bytes, or opens to an empty level. There is no recovery, because the only copy of your level was that file.
You spend an evening rewriting the movement Blueprint. It is worse. You cannot remember what the old one looked like, because you saved over it eleven times getting here.
Lost, snapped, left in the machine in G-022, or quietly corrupt for the last fortnight and you only find out the night before hand-in.
Two people open the same level. Both save. One of those two people's work no longer exists, and nobody can tell you which.
College machines get re-imaged. Anything sitting on the local drive of the PC you used on Monday might not be there on Thursday, and nobody owes you a warning. If your project lives in a {{repo|repository}} on GitHub, you sit down at any machine on any campus, pull it down, and carry on. That alone is worth the setup.
Strip away the jargon and it's a project folder with a memory. Git watches the folder. When you tell it to, it takes a snapshot — a {{commit|commit}} — and stores it with your name, the time, and a one-line note about what you changed.
Your actual Unreal project. What the editor opens and what you break.
A snapshot with a message. Local to your machine. Takes seconds.
Uploads your commits to GitHub. This is the bit that makes it a backup.
The copy that survives your hard drive, your USB stick and the re-image.
A commit that hasn't been {{push|pushed}} is not a backup — it's still on the same machine that's going to fail. Commit often, push before you leave the room.
Git was built for text — code, not 200MB level files. Unreal is nearly all binary: .uasset, .umap, textures, meshes, audio. Plain Git handles those badly, which is why half the tutorials you'll find online end in someone's repo exploding.
The fix is {{lfs|Git LFS}}, and it is the reason this guide exists in this order. Set LFS up before your first commit and everything works. Set it up after and you get to learn what "rewriting history" means, on a Thursday, in a hurry. Section 04 is the important one — don't skip it.
This account is not just storage. It's the first thing a studio or a university looks at when you apply — a public, dated record that you build things and finish them. Set it up like it matters, because in about eighteen months it will.
xX_DarkSlayer_Xx. You can change it later, but every link you've given anyone breaks when you do.Both are free and unlimited. Coursework in progress: private — no arguments about who copied whom, and academic integrity stays simple. Finished projects you're proud of: public, so they're part of your portfolio. You can flip a repo from private to public whenever you like.
One person owns the repo and invites the others as {{collab|collaborators}} (repo → Settings → Collaborators). Everyone commits under their own account, so the history shows exactly who did what — which is remarkably useful when a group project goes sideways and someone claims they did most of it.
A real name, a photo that isn't a meme, and one line saying what you're studying. It takes two minutes and it's the difference between a page that looks like a person and one that looks like a bot. Add projects to it as the year goes on.
Git is the engine. GitHub Desktop is the dashboard. Git LFS is the thing that stops Unreal breaking it. Install all three before you go anywhere near a project — and yes, the order matters, because LFS needs Git to already exist.
These may already be installed — check the Start menu for GitHub Desktop before you try. If they're not there and the installer is blocked, that's an IT request, not a you problem. Ask your tutor. Do not spend twenty minutes fighting a permissions dialog.
Download from git-scm.com/download/win (or brew install git on a Mac). Run the installer and accept every default. There are about twelve screens and you have no reason to change any of them. Click through.
You will never open Git directly. It's the thing the other tools drive.
Download from desktop.github.com. Install it, then File → Options → Accounts → Sign in with the GitHub account you just made. It'll open a browser to authorise — that's normal.
Then File → Options → Git and check your name and email are filled in. That's what gets stamped on every commit you make.
Because you can see what you're about to do. The Changes list shows every file that's different, the History tab shows every version, and undoing something is a right-click rather than a command you found on Stack Overflow and don't understand. Professional teams use the terminal; you'll get there. Start where mistakes are visible.
Download from git-lfs.com and run it. Then — once, ever, on each machine you use — open a terminal and run:
git lfs install
You should get back Git LFS initialized. If instead you get "git is not recognised", Git didn't install properly or you need to close and reopen the terminal — reboot and try again before asking.
Normally Git stores a complete copy of a file every time it changes. Do that with a 90MB level file across forty commits and your repo is 3.6GB. {{lfs|Git LFS}} — Large File Storage — instead stores a tiny text pointer in the repo and keeps the actual file in a separate store, so the history stays small and cloning stays quick. You don't have to think about it after setup. You do have to set it up first.
Your project must be made in the same Unreal Engine version as the machines in CC-5-G-022. A project saved in a newer version cannot be opened in an older one — not "looks odd", cannot open. Ever. There is no downgrade path, and no amount of Git will save you, because Git preserves your file perfectly and the file is still unopenable.
Check the version on a college PC in the Epic Games Launcher, and install exactly that one at home.
Make one folder: C:\UnrealProjects\ — short path, on a fast local drive, and every project lives inside it. Short paths matter: Unreal generates deeply nested filenames and Windows still gets unhappy past about 260 characters.
Not Documents, not Desktop, and above all not inside OneDrive. OneDrive syncs files while Unreal has them open, corrupts them, and creates helpful copies called MyLevel-DESKTOP-4F2K1.umap. Git and OneDrive both want to manage the same folder and they will fight. Pick Git.
An Unreal project folder is mostly rubbish that Unreal regenerates on its own. Commit all of it and your repo is 12GB and takes an hour to clone. These two small text files, in place before your first commit, are the difference between version control that works and version control that ruins your week.
Content/ — every asset, level and Blueprint you make. The actual work.
Config/ — your project settings.
Source/ — C++ code, if you write any.
Plugins/ — plugins you've added.
YourProject.uproject — the file you double-click.
Saved/ — autosaves, logs, crash dumps. Gigabytes of noise.
Intermediate/ — build scratch. Regenerated automatically.
DerivedDataCache/ — a cache. Enormous. Rebuilds itself.
Binaries/, Build/ — compiled output.
.vs/, *.sln — Visual Studio's own files.
.gitignoreThis is the "never commit these" list, written down. It goes in the top level of your project folder, next to the .uproject. GitHub Desktop can drop in a ready-made Unreal one for you when you create the repo (section 06) — that's the easy route, and it's the one you should take.
If you need to write it yourself, this is the whole thing:
# Unreal generates all of this. None of it belongs in the repo. Binaries/ Build/ DerivedDataCache/ Intermediate/ Saved/ Platforms/*/Binaries/ Platforms/*/Build/ Platforms/*/Intermediate/ # Visual Studio / Rider .vs/ .idea/ *.sln *.suo *.sdf *.opensdf *.VC.db *.VC.opendb *.vsconfig # Compiled output *.dll *.exe *.pdb *.lib *.app # Operating system junk .DS_Store Thumbs.db desktop.ini
.gitignore only ignores files that aren't already being tracked. If you commit Saved/ first and add the ignore rules afterwards, Git keeps tracking it and cheerfully carries on uploading your crash logs forever. Ignore file first. Always.
.gitattributesThis is the LFS list — it tells Git which file types are too big for normal handling. Same place, next to the .uproject. The easiest way to create it is to let Git write it for you: open a terminal in your project folder (GitHub Desktop: Repository → Open in Command Prompt) and paste this block in one go.
git lfs install git lfs track "*.uasset" git lfs track "*.umap" git lfs track "*.fbx" git lfs track "*.obj" git lfs track "*.png" git lfs track "*.jpg" git lfs track "*.tga" git lfs track "*.psd" git lfs track "*.wav" git lfs track "*.mp3" git lfs track "*.ogg" git lfs track "*.mp4" git lfs track "*.ttf" git lfs track "*.otf"
Each line adds a rule to .gitattributes, creating the file if it doesn't exist. When you're done, check it worked — you should see the file listed with your changes in GitHub Desktop, and it should look like this:
*.uasset filter=lfs diff=lfs merge=lfs -text *.umap filter=lfs diff=lfs merge=lfs -text *.fbx filter=lfs diff=lfs merge=lfs -text *.obj filter=lfs diff=lfs merge=lfs -text *.png filter=lfs diff=lfs merge=lfs -text *.jpg filter=lfs diff=lfs merge=lfs -text *.tga filter=lfs diff=lfs merge=lfs -text *.psd filter=lfs diff=lfs merge=lfs -text *.wav filter=lfs diff=lfs merge=lfs -text *.mp3 filter=lfs diff=lfs merge=lfs -text *.ogg filter=lfs diff=lfs merge=lfs -text *.mp4 filter=lfs diff=lfs merge=lfs -text *.ttf filter=lfs diff=lfs merge=lfs -text *.otf filter=lfs diff=lfs merge=lfs -text
Commit the .gitattributes file itself. It's part of the project. If a teammate clones your repo without it, their machine won't know about LFS and things get strange quickly.
A free GitHub account gets 1GB of LFS storage and 1GB of downloads a month. That is plenty for a coursework project and nothing at all if you commit a Quixel Megascans library. Keep your project lean: delete assets you imported and didn't use, don't commit 8K textures for a game that renders them at 512, and think before you drag in a 2GB asset pack. If you hit the limit, pushing stops until you clear space or pay — and "GitHub won't let me push" the night before hand-in is not an extenuating circumstance.
Unreal has version control built in — it's called {{rc|Revision Control}}, and it can talk to Git. Once it's connected, the Content Browser shows you which assets you've changed, and you can look at an asset's history or roll one file back without leaving the editor.
git.exe and the repo root by itself and shows them both. If it can't find Git, point it at C:\Program Files\Git\bin\git.exe.When the project isn't in a repo yet, this dialog offers to create one, add a .gitignore, add a .gitattributes for LFS and make the first commit. That works — but you get more control doing it in GitHub Desktop, which is what section 06 walks through. Do it there; come back here afterwards.
Small marks in the corner of each asset thumbnail: changed, added, up to date, or being edited by someone else. Genuinely useful — a glance tells you what you've touched this session.
On any asset: History (every version, with messages), Revert (throw away your changes to just this one asset), and on a team repo, Check Out to lock a file so nobody else can edit it.
It's marked beta and it earns the label. It's excellent for seeing status, viewing an asset's history and reverting a single file. It is less reliable for the day-to-day commit-and-push cycle, and it can hang the editor on a big operation.
So use both, and use each for what it's good at: the plugin inside Unreal for status, per-asset history and file locking; GitHub Desktop outside Unreal for committing, pushing, pulling and anything that involves undoing. That's not a workaround — plenty of studios work exactly this way.
Stop reading and do this one. Fifteen minutes, start to finish, and at the end you'll have a real Unreal project on GitHub. Use a throwaway project — the point is the process, not the game.
C:\UnrealProjects and the name to SavePointTest Unreal creates C:\UnrealProjects\SavePointTest\. Click Create.Maps, name it TestLevel, save. Now there's a real file on disk to track.C:\UnrealProjects\SavePointTest and choose it.git lfs track lines). Press enter, wait, close the terminal window.Back in GitHub Desktop you should see roughly 20 to 60 changed files: your .uproject, things under Config/, your TestLevel.umap under Content/Maps/, plus .gitignore and .gitattributes.
If you see thousands of files, or anything under Saved/, Intermediate/ or DerivedDataCache/, stop. The ignore file isn't doing its job. Open .gitignore in Notepad, paste the version from section 04 over the whole thing, save, and check again. Fixing this now takes one minute. Fixing it after you've pushed takes an hour and someone else's help.
Initial commit — empty project with LFS set up. Then click Commit to main.SavePointTest. Tick "Keep this code private" for coursework. Click Publish.On GitHub, click into Content/Maps/TestLevel.umap. If LFS is working you'll see a note saying "Stored with Git LFS" and a file size. If instead you see a wall of garbled characters, LFS isn't tracking it — the file went in as a normal binary. Go back and check .gitattributes exists and has the *.umap line, then ask for help before you build anything else on top of it.
Your project folder is now watched by Git. There's a snapshot of it saved locally, and a copy of that snapshot on GitHub's servers. If your machine dies right now, you lose nothing but the walk to a different machine.
This is the entire day-to-day of version control, and it's three steps long. Do it now with something trivial, so that when you do it with three weeks of coursework your hands already know the moves.
Do the work. Ctrl+S. Nothing else is different.
Tick the files, write what you did, Commit to main.
Push origin. Now it exists somewhere other than this PC.
SavePointTest again And open TestLevel if it doesn't load automatically.Content/Maps/TestLevel.umap is now sitting in the Changes list, on its own. That is the repo noticing.Add a cube to TestLevel. Commit to main.Go back into Unreal, delete the cube, drop in a sphere instead, save, commit as Swap the cube for a sphere, push. You now have three commits and three different versions of that level saved forever. That third commit is the one you'll roll back in the next section — so don't skip it.
You are writing a note to yourself in six weeks, when you're looking for the version from before everything broke. update tells that person nothing. Pick a message below and see the difference:
Commit when you've finished a thing, not when you've finished a session. Got the jump height right? Commit. Built the main menu? Commit. Ten small commits with clear messages are worth far more than one at 4pm called work, because you can only roll back to the points you made.
Push at least once per session, before you leave the room. A commit you haven't pushed is still on one machine, and one machine is not a backup.
Everything so far has been insurance. This is the claim. There are three different undos depending on how far you've gone, and knowing which one you need is most of the skill.
Close Unreal before you undo anything. The editor holds assets in memory. If you restore files on disk while it's open, Unreal doesn't know, and the next time it saves it writes the old version straight back over your recovery. Close the editor, do the undo, reopen the editor. Every time.
You changed something, saved, and immediately regretted it. The change is on disk but not in a commit.
In GitHub Desktop, right-click the file in the Changes list → Discard changes. The file goes back to how it was at the last commit. To bin everything since the last commit, right-click in the empty space and choose Discard all changes.
This one is not recoverable. Discarded work was never committed, so there's no version of it anywhere. Read the file names before you click.
This is the one you'll actually use, and it's the drill. You committed the sphere. You want the cube back.
Swap the cube for a sphere one. Choose Revert changes in commit.Revert "Swap the cube for a sphere". Your history stays honest — the mistake is still on the record, and so is the fix.You just deleted work and got it back in under a minute, without a USB stick, without emailing yourself a zip, and without losing anything else you'd done since. Do this once now on a test project and you'll trust it in March when it's your actual assignment.
Sometimes you don't want to roll back a whole commit — you've wrecked one Blueprint and the rest of the session was fine. That's what the {{rc|Revision Control}} plugin is genuinely good at.
On github.com, click Commits, then the <> icon beside any commit. You're now browsing the entire project exactly as it was at that moment. You can download a zip of the whole project from that point in time via Code → Download ZIP — useful when you want to look at an old build without disturbing your current one.
Discard changes — not committed yet, throw it away, gone forever.
Revert commit — committed, undo it safely, everything is recoverable.
Revision Control → Revert — one asset, from inside Unreal, uncommitted changes only.
Git was designed so that several people can edit the same file at once and have their changes combined automatically. For text, that works beautifully. For Unreal, it does not work at all — and understanding exactly why is what stops your group project falling apart in week nine.
A .umap or .uasset is compiled binary data. Git cannot look inside it, so it cannot combine your change with someone else's. When two people edit the same asset, Git can only offer you a choice: keep mine, or keep theirs. One person's work is deleted. There is no third option and no clever command that rescues it.
Everything below exists to stop you reaching that choice.
First thing, before you open Unreal: GitHub Desktop → Fetch origin → Pull origin. You're now working on top of what everyone else did. Skip this and you're building on a version that no longer exists.
Non-negotiable in a group. Work sitting uncommitted on your machine is work your teammates will unknowingly duplicate or overwrite.
Decide who has the level before anyone opens it. Say it in the group chat so there's a record. "I've got MainLevel this afternoon" costs three seconds and saves an evening.
Two people can happily work on two different Blueprints at the same time. Two people cannot work on the same level. Divide the project into separate assets early, and use Unreal's Levels panel to split one big map into sublevels people can own individually.
Git LFS can make asset files read-only until someone locks them. To edit a file you check it out, which locks it on the server; everyone else physically cannot save over it until you check it back in. This is how commercial studios work, and it's the only mechanism that actually enforces rule 3 rather than trusting people to remember it.
Add lockable to the asset lines in .gitattributes:
*.uasset filter=lfs diff=lfs merge=lfs -text lockable *.umap filter=lfs diff=lfs merge=lfs -text lockable
Then in Unreal: Edit → Project Settings → Revision Control (or the Revision Control settings dialog) and turn on the Git LFS file-locking option. From then on, right-click an asset → Revision Control → Check Out to claim it, and Check In to release it and commit.
With locking on, every asset is read-only until you check it out, and Unreal will refuse to let you save one you haven't claimed. That feels broken the first time it happens — it isn't, it's the system working. Also: check your files back in before you go home, or your group spends tomorrow morning locked out of files nobody can edit but you.
A {{branch|branch}} is a parallel copy of the project where you can try something risky without touching the working version. They're powerful, and they're also where beginners lose work, because merging a branch full of binary Unreal assets hits exactly the problem at the top of this page.
For your first group project: everyone works on main, commits small, pushes often, and talks about who has what. Come back to branches once that's second nature — or when you're writing C++, where merging works properly.
Tick these off before you leave the room. Every session, group project or not.
It will. These are the ones that actually happen, roughly in order of how often. Find the error message, read the fix, and if the fix involves the words "ask for help" then genuinely do that rather than guessing — most unrecoverable Git disasters started as a recoverable one plus twenty minutes of improvising.
Before you try anything from the internet: copy the error message somewhere safe, and copy your whole project folder to a second location. A duplicate folder on your desktop costs you two minutes of disk copying and means that whatever you do next, the work still exists. Then fix it.
Every one of these is something that has actually gone wrong for a student on this course. Get them right here and you get to skip the version where you learn it the other way.
Git's vocabulary is genuinely bad — half the words mean something different from their normal English meaning. Here's all of it, without the pretending.
Ask in class, or email JBell@belfastmet.ac.uk. Bring the exact error message — a screenshot of the actual text beats "it says something about a head" every time.