Introduction

As mentioned in an earlier post, despite the low post count, this site has existed in some form for several years. I originally started off using Pelican as the generator but migrated to Hugo due to what I perceived as a drop in development activity, especially in the theming space. I’ve largely been happy with the move, while I am not a Golang developer, my dev experience is in Python, I found Hugo fairly easy to adapt to and more importantly - verbose enough with its errors to make it work.

One thing I wanted to get right from the beginning (and from my own prior mistakes) was organizing the project so that I could work on the different areas independently of each other by using multiple Git repos.

I won’t be going into the details of setting up the AWS components to serve the HTML or of Hugo itself. There are plenty of articles available that document those. Some day I might do a write up to pull them together.

The Lay of the Land

When I was setting up my project I quickly realized that I wanted to make sure I maintained separation between the site project which houses the logic (site configurations and customizations), presentation (theme), and content (posts and pages).

As the project resides in Git, it consists of three Git repos. The site project and content repos are maintained by myself. The theme repo, Hugo Clean White theme, is maintained by Huabing (Robin) Zhao.

The site project repo is a “master” repo which wraps around the other two. The theme is a Git submodule of the project repo located at ./themes/hugo-theme-cleanwhite, that way I can pin to a release for production (main) and use branches to test new releases of the theme from the developer. The content repo is just an independent repo that is not a submodule but rather cloned directly within the project repo as ./content. I silence the Git detection of the ’not tracked’ files by adding content/ to the project repo’s .gitignore.

From the directory/file perspective, everything looks like one big happy family but from a Git perspective it kind of looks like:

My thinking is that I will not be making customizations to the Hugo theme itself, instead relying on overrides in the layouts/ directory of the site project repo. If there ever comes a day where that becomes too unweildy or I am unable to accomplish something without touching the original theme files I will spin it out into its own fork of the original or depending on how different things are, into it’s own new theme project.

With the content as a separate tracked repo I have the freedom to make design and functionality changes independent from creating content. As an added bonus it is trivial to try out new themes with existing content.