In this post, I describe updates to my blogging workflow.

When I first started this blog, I followed a simple master push workflow. This was easier to simply make an edit to a file and push the changes to see the result live. This approach treated the entire aniemsh.gitlab.io repository like a regular software project. It was effortless to write something and see it live without much ado.

After all, how much overhead does a single developer need?

As the repository started growing in size, it become unwieldy to mix blog post drafts with design changes and experimental features. So I decided to use a better workflow to manage writing content and adding technical or functional features easier.

I came up with the following model with two types of branches.

Few Permanent branches

  1. Master branch where I write new posts, renew ssl, update project meta information (README, plugin, CI) or any other emergency fixes
  2. Design branch for significant behaviour, style or structure modifications to the blog.

Several long running feature branches

  1. feature-series-posts
  2. feature-toc

These should be short lived ideally, but the fact that I am the only developer on this project, would not afford me as much time I would like. As a result, working on a feature is the hardest thing to do as compared to making a design update. Hence the long running branches. In terms of their utility, these branches are still short-lived.

This worked until now. These days I am using a merge request workflow in my work projects. I thought about giving the merge request workflow a try for my blog.

To accommodate this, I need to adjust the above model a bit by adding a new permanent branch.

  1. Drafts branch for writing new posts and raising merge requests for publishing posts.

The branching strategy, roughly speaking, becomes the following.

Whenever there is a design change or a new post

  1. Raise a merge request.
  2. Reverse merge master into other permanent branch(es) frequently

Whenever there is a new feature

  1. Merge into design branch for testing with current design
  2. Raise a merge request
  3. Reverse merge master into other permanent branch(es)

For this to work, I have protected push to master, even from the Maintainer (me). This has an added advantage of not running the pipeline each time a careless push makes its way into master.