I am finally ready to start building a new website using a static site generator (Hugo). The question I have, is how do I separate the content, the theme and the site itself in different repositories, but bringing it all together in one directory on my computer?
So in GitHub I would have 3 repositories: site, content (blog posts, pages and images) and theme.
On my home computer it should look like this:
|_ site (repository)
| |_ ... (files, folders and config files for the site)
| |_ content (repository)
| | |_ ... (pages, posts and images)
| |_ theme (repository)
| |_ ... (theme files and folders)
|_ ... (other repositories)
Is this what submodule is for? Or are there other solutions?
I want to independently commit changes for each repository (site, content and theme).
So when I commit changes to the site, they should not include the content or theme files and folders and vice versa. Does submodule take care of that or should I use a .gitignore for the site repository that excludes the content and theme folder?
If you could point me in the right direction (and manual), that would be great.
I would still use a single repository personally
but, to comment a couple of things you said
commits can have as many or few changes as you want, and also a commit register only the changes to the files you made for that commit, not the whole repo
This is going to be an absolute nightmare to manage. It is going to make development very painful, for afaics no benefit. What is your reasoning for trying to do this?
You now have three seperate pieces of code in three seperate places can’t work in isolation and can only work when joined together. You in fact will have four repos, because you need the overall project as well (the repos are subfolders in this). But you now have git repos in a git repo, so to keep git working, the three sub-projects need to be submodules. They are still seperate things, so to commit changes, you have to make changes in the relevant repo (bearing in mind it the contents of that repo isn’t going to be executable code and doesn’t actually do anything in isolation), then push, then in the main repo pull in the updates to the submodule.
This is a crazy workflow, I’d strongly suggest not doing it. Note also that if you do persevere with it, it’s near-inevitable that you will screw it up, due to its complexity.
I believe it is usual to “install” a theme as a submodule (after forking it). If I want to make my theme later publicly available it has to be separate from my site and content. I was wondering if a submodule is the right way to do it and if it would make sense to put the blog posts in a separate repository as well.
Total is 3 repos, max: theme and maybe content, and the site is the overall project.
Using a single repository would mean that I cannot make my theme publicly available later.
It sounds like it is important to you to use submodules. They are not recommended in the majority of cases and they greatly increase complexity. I would avoid them, but if you really want to use submodules, it’s your project.
No, I do not have a desire to use submodules, I want to at least keep my site and theme in separate repositories so that if I want to make my theme publicly available I can do so and my site and blog repository remain private. I want to know if submodules is the right way to do this in git.
It seems that the standard way to distribute Hugo themes is with submodules, but that does not obligate you to turn every folder in your site into a submodule. That will be a pain in the neck to manage. You want to use as few submodules as absolutely possible.
Other static site generators have ways to publish themes so you can bypass the submodule tomfoolery. I’m not sure why Hugo doesn’t.
In which case, just put everything in the same repo, and if at some point you want to distribute your theme, only at that point do you have any need to extract it to a seperate repo. Doing this up front simply makes things extremely complicated for very little benefit.
Edit: don’t lose sight of the fact that you’re trying to publish a blog. What you’re talking about here is busywork, and that busywork is just going to turn into an excuse to not do the blog side of things. It’s going to take a constant non-trivial amount of fighting with git to get anything done, and you will get very bored of that