This workshop is intended to give a little insight into how a typical software engineering company might handle workflow and code merges. Usually, there will be a parent repository, and each teammate will fork the repository. The teammate will work on changes to their own fork, and after a feature is finished, they'll make a pull request to the parent repository. The other teammates will give them a code review - checking to make sure their new code is correct, clean, and sufficiently tested. Depending on how the code review goes, the pull request could either be accepted, in which case the code is merged into the parent repository, or rejected, in which case additional changes are requested.

Part 1: Basic set up

• Fork this repository
• Clone your fork onto your local machine

Part 2: Work on your local changes

• Try to improve the readability / cleanliness of the code
• Add more unit tests
• Commit and push your changes to your fork's master branch

Part 3: Make a pull request to the parent repository!

• After you make a pull request, one of your teammates (me in this case) will be able to review your code and add notes about your changes
• If your changes look good, I'll write a LGTM (looks good to me) and merge your code into the parent repository!
• If your changes could use some fixing, I'll request additional changes. At this point, you could just commit directly to your repository, and it will show up in the pull request automatically.