Workflow

Over the years, I have worked on a few projects where I was the sole developer. Being a sole developer has its challenges since not everyone reviewing your pull requests (or merge requests for the Gitlab folks) has an understanding of the repository like I do. Because of this, I like to give a bit more context to every pull request I create so reviewers know what to expect when reviewing code.

In this post, I am primarily focusing on pull requests regarding front end development and working on SaaS software, but this format could work for others too. My typical pull request is broken into four main sections: context, testing, checklist items, and then any related GitHub issues or JIRA tickets that will be closed as a result of the merge.