I’ve decided to write this tutorial out of seeing this increasing need for people to back up their projects. I can’t actually stress this one enough. Back up your projects! At least once a week I see something like “help, my PC crashed and my files are corrupted!” Did they have a backup? Nope.
So, this tutorial is to help people make sure they have a backup. Not just a copy on Dropbox or some such, but real, proper version control.
RCS – Revision Control Software
It sounds complicated, I know, but it’s really pretty simple. Revision control software, when used correctly, tracks all changes made to all files in your project, who made those changes, when and even allows you to go back to any change on any file throughout the history of your project. Pretty cool, right?
“But wait,” I hear some people saying, “isn’t that just for big companies and huge software? That’s way to big and complex for someone like me. And probably expensive, too!”
Not really. Keeping your project’s files and progress safe should be your number one concern. Not getting feature x, y, or z in. Not getting your demo out. Keeping your project safe. It’s really easy to give into enthusiasm and dive into development, but if you’re not working to keep your files safe, then disaster is quite easily right around the corner.
Bitbucket – Free, Easy and Private
Most people have heard of Github as a place to store their projects, but I tend to prefer using Bitbucket for one simple reason: Bitbucket can have private repositories for free, while Github cannot.
What does this mean to you? It means that unless you have a paid account with Github, your project will be stored in such a way that anyone can come along and pull your project files, assuming they find your project. To me, this is not ideal. I want my project files to be mine until I decide otherwise.
So, for this tutorial, using Bitbucket, and their associated tool SourceTree (covered later) is what we will be looking at. Github is probably pretty similar, but you’ll have to pick a different tool to work with revision control.
Bitbucket Registration
Registering for Bitbucket is pretty much what you would expect for registering for a website. Head on over to https://bitbucket.org/account/signup/ to register your account.
The Dashboard
Once you’re registered and logged in, Bitbucket will take you to the default main page – the Dashboard.
To create a new repository, Click Repositories at the top of the page, and click on Create Repository. This menu also shows the recent activity for your current repositories.
When setting up SourceTree or a repository, it may ask you for an SSH key. Just click Cancel on that window (despite the fact that it tells you that you can click No).
Setting Up Your Repository in SourceTree
The new repository page does have a Clone in SourceTree button on it, but if your luck is anything like mine, clicking that will do absolutely nothing. If it does work, I don’t really know what to tell you to do next – it never has worked for me!
Make sure you clear out those Music and Sound sections – unless you know for sure you’re going to be keeping them. Additionally, clear out the Vehicle Images, and even the images for the SV Attack Motions. Remember to set the Title Screen image to none and/or uncheck Draw Game Title.
If you do plan to use parts of the RTP, feel free to leave them in, but do remember that you will need to selectively delete files from the project folders so that you don’t remove those. Ideally, if you have a single actor with no graphics set on that actor, your project should still be capable of running without crashing. If any of the system files are removed without changing them, the game will not run and will inform you of what file is missing.
For the most part, that’s all there is to using SourceTree and Bitbucket. If you’re working on your project across more than one computer, or you’re working as part of a team, you’ll need to use the Pull command, which goes to the server and gets all files that have changed between the version you have and the version it has. In these cases, it is extremely important that you use Pull before starting work on the project, even if just to confirm there are no changes. If you do not, it is possible the work you do will cause a Conflict.
Conflicts
Sometimes when more than one person is working on a project, there will be problems called Conflicts. This occurs when two different versions of the project both show different changes to the same file. Through some kind of magic awesome technological stuff I don’t entirely understand, the system knows the difference between your changes to a file and someone else’s changes to that same file. Unfortunately, due to the nature of many, especially older, RPG Maker files, the process called merging is extremely difficult or downright impossible to do. In the case of a conflict, your only options are to use the local (your changes) or remote (someone else’s changes) version of the file. If you are working in a team and a file conflict occurs, talk it over with your team before blindly overwriting the remote files.
Updating With Your Changes
When working on your project, you can work directly with the files in your local copy of the repository. SourceTree will track any changes you make and is always ready to help you get them into revision control. Afterward, it’s the same process as the commit and push of the original project – give it a description, check the checkbox and click Commit.
Looking Back
You can look back at the history of your project at any point in time by selecting your repo on the far left side, clicking the little toggle arrow beside origin under Remotes (if it’s closed) and clicking on master. Master is the main “branch” of your project, and assuming you have not made other branches, is all that will be listed in here. In the main window to the right, a list will be shown of all commits to all branches of the project. If you have multiple branches, you can select which one to view information on.