Decoupling Git and my Jekyll work

I’m experimenting with a new way of using version control on this Jekyll-powered website, I thought I’d share in case it was useful for someone.

I will state the problems, what I used to do, and what I’m going to try out.

The problems

I have one article I want to write at any given time, but sometimes that article can take days to write and in the interim I might have small tweaks, or different articles I want to get out.

I also want to have articles scheduled to be posted at a date in the future.

Finally, I have several articles that I want to have in a draft state. These aren’t the main thing I’m focused on, but something I’d like to have ticking away in the background.

Jekyll has the ability to handle both drafts and posting in the future, and git has the ability to use branching to mean I can easily come back to an in-progress article. The issue is combining these three needs together can feel a bit clunky, I don’t want to have to merge a PR with a completely work in progress draft in it, but I also want access to it across all my branches.

How I was solving this

The way I approached this before was branching based on the main article. We store our article ideas in Github issues, so the branch might be called something like 1431-rails-migration-guide.

If an article was going to take longer than a session to write, I would commit it as a draft and if I needed to take a break from it I would branch again from main on my new topic.

Once an article was ready, I would move it from the _drafts folder, rename it to suit the date I wanted it to go live onm and create a PR.

This works fine, but often when I’m writing one article I have an idea for improving or drafting an unrelated article. I could add my thoughts to the issue, but sometimes that felt like more effort than it was worth.

What I’m moving to

What I’ve started experimenting with is a branch name of today’s date, e.g 2024-08-04, which is always branched off of main and always showing the next state of the website that I want to deploy.

This should help me be a little more fluid with what I’m writing, whilst still maintaining a decent Git history by staging commits with appropriate mentions of the issue numbers I’m addressing.

At the end of my work, I will send the branch up for pull request, and get it merged in.

If there are issues, I won’t start working on another branch until those have been resolved.

This feels like less process, but still an appropriate amount of rigor. Let’s see how it goes!