Source Control

As the name suggests, we control code changes going into a production codebase. There’s quite a few methods in place to do this, so we’ll go over that. But first, here’s a quick breakdown of my contributions:

  • Srum Master of Scrum Masters for Platformer4x Development
  • 522 contributions in 2024
  • 228 contributions in 2025
  • 100+ PRs managed
  • Admin for Platformer4x and Platformer4x-LEAAAAM

Forking

Forking is, simply put, just making a copy of some repo and allowing you to make changes to it. Your fork therefore diverges from the main repo.

Ok, but why would I want that?

Well, if you want to control the code changes going into a production codebase, you want people to be able to make contributions. However, generally speaking, you don’t want to give everyone admin permissions, since it’s a massive security vulnerability and creates a codebase prone to going offline VERY frequently. Thus, we use forks.

I myself generated a fork Platformer4x-LEAAAAM to lead my development team, then had those changes made on the fork pushed to the production repo.

Branching

Ok, but what if I want multiple people working on that fork? Will I they have to make forks of the fork? The answer is no. Instead, we use something called branching. Branching is creating internal copies of the fork. That is, the fork diverges from the production codebase (making a copy, then adding changes), but branches then diverge again from the fork so multiple people can contribute to one fork.

For example, structure could look something like this:

prod
 |_fork
    |_branch1
    |_branch2

Idea behind branching is that one dev can work on branch1 and another on branch2, where they make seperate commits. These commits are then merged (more on that later) into the fork, and from the fork into the production database.

Building & Testing/Verification

To ensure that the site actually runs correctly, we have things called build jobs (usually called CI pipelines on larger development scales) which run tests to verify the integrity of the code. Bit of a caveat to this, it doesn’t fully verify bugs or anything like that, it just ensures it runs.

For the Platformer4x development structure, Jekyll (tool used to deploy static websites) build jobs were run on both the production codebase (actual deployment), forks (testing stage 2), and branches (testing stage 1). The build job just makes sure that the site correctly builds and deploys, which is a good verification before we push to the main production codebase.

Check out this example of a build runtime log and this more UI friendly version of it

Pull Requests and Merging!

Probably my favorite part here. Merging is the act of merging your code with some other code. Say, for example, you edit a file and add the text "meow" to the bottom of it which you have done in a branch you created. You want to integrate these changes with the main branch right? To do this, we need to merge the code. Github will automatically see if there are any conflicts caused by editing this code (usually happens when somebody else edits that same file and pushes it to main before you do, so your version of the branch is out of date, and thus a merge conflict arises) before, and then go through with the merge by adding your edit to the main branch.

Now, say we wanted to get code from the fork to the production codebase. To do this, we can’t just merge it (you’d need admin permissions to do that). Instead, we use Pull Requests (PRs). PRs requets containing changes that we want to integrate into a codebase (typically accompanied with a short description by general practice). When a Pull Request is made, Github will automatically check for merge conflicts again before merging. When we do, the changes made in your fork are compared to the production codebase, and if no errors arise, your changes will be mergd into the production codebase.

CSSE Implementations

  • You can check out my Github history for some seemingly randomly picked software development acivity here
  • Pull requests on Platformer4x (which I’m typically the one managing) here
  • An example of a fork Platformer4x-LEAAAAM here
  • Examples of commits, branches, and merging here
  • And finally, examples of build checks here