Coder Intro Part 3: Submitting a Pull Request

Pull Requests

Now that you've created a simple microgame, you're going to submit it to the main NitoriWare repository on GitHub using something called a Pull Request.

Pull requests are a great way for coders to submit completed code branches to the primary repository. They let other coders on the project easily review the changes and merge them in if they're suitable.

First, lets look at checklist of things that you should have done up to this point. If something is missing, go back to a previous section and try it again.

You should have

• forked the https://github.com/NitorInc/NitoriWare repository.
• made a clone of this fork somewhere easy to access on your computer.
• created a new branch called "Microgame/ReimuDodge/basic-functionality" which is set up to push commits to your GitHub fork.
• opened the project in Unity 2017.3.X
• followed the ReimuDodge microgame coding tutorial and created your own microgame within your branch.

Submitting your code as a Pull Request

1. Push everything

Make sure all the changes on your local branch have been pushed to your repository on GitHub.

Also, it might be a good idea to read through the microgame PR guidelines just in case you've missed anything

2. Find your branch on GitHub

Next, head over to your fork on GitHub and find your "Microgame/ReimuDodge/basic-functionality" branch. Select it.

3. Create the PR, review changes and submit

With the branch selected, hit the "New pull request" button next to the branch drop-down.

If you pushed the branch recently, you can also go to the main NitorInc/NitoriWare repository and create a pull request from there:

If everything worked, you should be able to see a list of all of the new files you've added for your microgame. Do a quick scan to make sure everything looks OK and then go ahead and submit the PR using the big green button, you can also add a comment if you like.

This will send a notification to #git_updates on our Discord server and a Code Kappa will check over it over.

While a PR exists for a branch, any new code or changes pushed to that branch on GitHub will be added to the PR automatically. So, it should be fairly easy to make extra changes if you need to.

4. Wait

If your PR gets accepted, you're ready to code your first microgame. Although, it might take a little while to organise your team. If any of the microgame suggestions pique your interest, or you have your own idea of what you want to make, let one of the Great Kappa on discord know and they'll see what they can do.

Don't be discouraged if we request some changes before we can accept your tutorial branch. Nobody's perfect, and we're just trying to help you become the best code kappa you can possibly be!

Anyway, give yourself a pat on the back and take a breather. And while you're waiting for a response, check this stuff out:

---

NitorInc PR advice

There are no hard-and-fast rules for how and when to submit a pull request for your microgames. But, to work efficiently and let others in the team to help you out as much as possible, here are a few useful things to keep in mind:

• Aim to submit pull requests of your code as often as possible!

  GitHub makes submitting PRs very straight-forward (providing you've followed the advice on keeping your fork and branches healthy). It can be very hard to think of your code as "PR-ready" and there will often be bits missing or things you're not happy with. Regardless, it is much better to PR soon and get feedback than not PR at all.

  With that in mind:

• Break up development into manageable chunks, organised by PR type

  Each branch you make should have a set goal and logical name to help you and others remember what is being changed and what the scope of the corresponding pull request will be.

  Below are some recommendations for branch names that you can try:

  • Microgame/<Microgame ID>/prototype for adding bare-bones mechanics and proof-of-concept features.
  • Microgame/<Microgame ID>/basic-functionality for when you have a clear understanding of how the game will work and can flesh out the scripts and scene layout so that the game is, at least, playable.
  • Microgame/<Microgame ID>/add-difficulties would add the level 2 and 3 difficulties and whatever adjustments, extra scene variables or alternate artwork that goes with them.
  • Microgame/<Microgame ID>/add-animations could be used if the game is very animation-heavy and implementing them involves a lot of sprite work and fine-tuning.
  • Microgame/<Microgame ID>/implement-review-X-changes is a special case example. Sometimes upon a PR getting accepted, we may give you back a review with an expansive list of things we want to be touched up, fixed, improved, etc., especially when you're programming your first couple microgames. Since this is sometimes enough for a new PR itself, this is a good branch name to address it with. Replace "X" with the review number you'll be given.

  Keep in mind that every microgame is different and some branches may not be applicable for you. For example, the prototype branch might only be needed for games that use complex mechanics which your team hasn't fully settled on, yet.

  The order in which you end up submitting PRs may also vary depending on how many of the art assets are complete. You might, for instance, end up adding all of the animations right away and working on difficulties, or even basic gameplay, much later on.

  It's also worth mentioning that it is OK for small things, such as a finished music track, to be added at any point. Do not worry too much about keeping each branch in scope; the important thing is that you use a system that makes sense to you and feels useful, and that people reviewing your PRs can understand what is going on.

---

The bonus section of this guide will contain additional, useful information that might help you if you get stuck later on.

Further reading material for coders can be found on our Contributing Microgame page. Finally, keep the Microgame PR Guidelines page handy for when you submit your for-real pull requests.