Using pull requests for proof reading

After launching my new site, I realised that, now that all of my blog posts were stored in the file-system, and directly pushed to Git…

…I decided to use one of Git’s better known features to allow third parties to review any new posts.

My ‘workflow’

…if you can call it that.

The instructions on how I manage my post creation workflow are as follows:

• I check out a new branch (i.e. the branch this post is being updated on is post/using-pull-requests-for-proof-reading)
• I write the post, including all of its required frontmatter.
• I push the branch, as normal.
• I use the GitHub pull request UI to open the PR and allow people to review.

To have another individual review your posts, you can request a review from the pull request page. A reviewer does not have to have push access to the repository, but they will have to be added as a ‘collaborator’.

Any modifications to the post will be automatically added to the pull request.

The workflow of this site also includes a “preview” feature on pull requests that is managed by Vercel, the hosting provider that I use to manage the builds of the site.

Also, this post itself is in this pull request system.

The catch

Branch names, which in this case, correspond to the format post/<title>, can only be a total of 244 characters on many Git providers, such as Github (excluding the preceding refs/heads/ before the branch name), so your post titles can’t be obscenely long. This catch may differ depending on what Git software you’re using to manage this system.