Using git to save your work and collaborate

[Emral]

I know a lot of you probably already know about git, since the term "repository" has been used more commonly recently as several smbx-related projects have had their source code posted. But this is a topic for those of you who don't yet use git for your episode or standalone levels.

Organisation is a big aspect of working on long term projects, especially as they get bigger (be it in terms of scope or in terms of the team size). As time goes on, the idea of something going wrong or at least being a really demotivating jank-fest becomes more of an inevitability than a possibility. Think a team member only sending levels through discord and you having to put them into the episode. Or you experiencing a PC malfunction that renders half the project's progress lost. Those are nuisances you shouldn't have to work with.

Thankfully, programmers decades ago had the same issues and developed version control software to back up every snapshot of their projects in case something goes wrong, or unusual circumstances happen. One of the most popular version control systems is git. If you've ever wondered why there has been no fatal accident during the development of SMBX2... well, there were a couple that would be fatal without git, but we were able to just roll back one version and undo the breaking changes. It's like nothing ever happened.

For the rest of the thread I will be solely focusing on git. There are other version control systems out there, but this is just the one I'm familiar with and feel qualified to talk about.

WHAT IS GIT?
Git is a version control system that makes it easy to back up changes and roll back accidents. In its simplest form, the use of git comes down to just a few steps:
- Staging all changes you have made to the project, which you would like to back up
- Giving that batch of changes a "commit message"
- Committing and pushing that batch to the remote repository, a storage of the entire git repository hosted on a git hosting site such as
-- https://github.com/
-- https://about.gitlab.com/
-- https://bitbucket.org/

BENEFITS OF USING VERSION CONTROL FOR YOUR WORK
Once a batch has been committed, the server hosts those changes, so even if your computer goes up in flames, nothing is lost. It's like a cloud storage, except it's also a bit cooler. I won't go into many of the complicated cool reasons, but here's just a few:
- Since the repository is remote, anyone you invite to work on it can join in. It makes working in a team on projects such as episodes very easy.
- Git allows you to "pull" changes other people have made, and as long as there are no merge conflicts, your local copy will be updated instantly without you having to manually move files around, or explicitly downloading any zip archives individually
- Git allows you to create parallel branches, so if for example someone is working on the master (main) branch, working on world 2 levels, someone else can create a "world_1" branch, where they can remove all non-world-1 features in peace to prepare for a world 1 demo.
- You can have multiple, separate repositories.

OKAY SOUNDS COOL BUT HOW?
Step 1: Make an account on one of the previously mentioned hosting providers (or any other of your choice)
Step 2: Download a git client. Sourcetree and Gitextensions are fairly popular and easy to use, but there are countless others, and you may prefer one not listed. Once you feel comfortable with the system, try some alternatives to see if you like those more!
Step 3: Getting started. Each of the hosting services listed above has a "getting started" guide. They're all fairly similar, but will point you into the right direction for where to find the buttons you need to push:
- https://help.github.com/en/github/getti ... ith-github
- https://about.gitlab.com/demo/
- https://bitbucket.org/product/guides/ba ... ting-steps
Step 4: Set up your git client. Here are the guides to the two I mentioned:
- https://git-extensions-documentation.re ... arted.html
- https://confluence.atlassian.com/get-st ... 59043.html
Step 5: "Clone" your repository (partially included in the prior 2 steps
Now you got your local copy of the remote repository. During cloning you decide in which folder it goes. If you already have content for what should go in there, you can now move your files over into that folder, and you can watch the git client update to reflect all the files you've added.
Step 6: Commit those files. You want to "stage" all of them, and then give them a commit message, commit them and then "push". Congrats! They're now backed up and you can't lose them again. This procedure is the standard git flow: Commit, Pull (to update in case a teammate pushed), Push. Do it a lot and you'll never lose your progress again.

That's pretty much it. There are a TON of guides on this subject, because pretty much every developer uses source control and wants others to also use it to keep their work safe, so if you're confused about anything, a quick google on what you're confused about will almost certainly yield useful results.

[Archived]

Archived

[Taycamgame]

Isn't it possible to also use a dropbox (etc.) directory rather than git? Since it's also available on the cloud.

[Emral]

Isn't it possible to also use a dropbox (etc.) directory rather than git? Since it's also available on the cloud.

In the first post I have given reasons for why git is superior.
(version control/rollback, multiple branches for easy collaboration, and one-click updates/rollbacks)

Yes you can use dropbox, just like you can manually copy a folder to an external HDD after every change.