Migrating my blog to Astro - Separation of code and data

I want to keep my primary blog repository on GitHub private, but still make the Astro scripts and structure public.

Blogging

This is part of a series of posts on how I migrated my blog to Astro

Astro logo

Since I moved my blog from Blogger to GitHub, all the content and Jekyll files have lived in the same Git repository. Initially the GitHub repository was public, but then I realised that sometimes when you’re drafting future posts, you want them to stay private until the appropriate time. True, this is a rare thing, but it’s better to be safe.

On the other hand, I really like the concept of open source software. The main way I learned how to use Astro was looking at other people’s efforts on GitHub. If I can ‘give back’ to the community in the same way then I would like to do that.

It took a bit of thinking on best to do this. Git submodules wouldn’t work as they assume that it’s a specific subdirectory that points to a different repository.

What I ended up with was this:

However, if you look at https://github.com/flcdrg/astro-blog-engine, the Git history only goes back to 1st February (as part of completing the Astro tutorial). So it’s completely unrelated to github.com/flcdrg/blog. So how’s that going to work?

What I did was tell git to allow me to merge changes from astro-blog-engine, even though their histories were unrelated by doing this:

git pull --strategy-option=ours astro-blog-engine main --allow-unrelated-histories

Now, every time I have enhancements or updates that I’ve tested in astro-blog-engine, I follow these steps in the blog repo:

git fetch astro-blog-engine
git checkout -b updates-from-astro-blog-engine
git pull astro-blog-engine main
git push

Then create a pull request and merge the changes in.

As long as I am careful to only make code/structural changes in the public repo and the merge them into the private repo, everything should be fine and I shouldn’t encounter any conflicts.

The second advantage of maintaining the core functionality in a different repository is that it is much quicker to test out changes. I have somehow accumulated over 1,000 posts, and that can take a few seconds (or sometimes minutes) to process.

To allow me to try out changes quickly without waiting for my full blog to rebuild, I’ve copied over just a few of the recent blog posts to the public repo. It’s enough to validate that everything works and there’s no regressions when updating a package or tweaking the TypeScript or layout.