- I create a content directory.
- Push changes there
- Create a website, add content as a submodule
1. Content Repository
Git local setup
Configure your Git identity locally to use it only for this project:
git config --local user.name "First Last"
git config --local user.email "myemail@example.com"
Git global setup
Configure your Git identity globally to use it for all current and future projects on your machine:
git config --global user.name "First Last"
git config --global user.email "myemail@example.com"
Create a new repository
git clone git@gitlab.com:my-blog/hugo-site.git
cd hugo-site
git switch --create main
touch README.md
git add README.md
git commit -m "add README"
git push --set-upstream origin main
Push an existing folder
cd existing_folder
git init --initial-branch=main
git remote add origin git@gitlab.com:my-blog/hugo-site.git
git add .
git commit -m "Initial commit"
git push --set-upstream origin main
Push an existing Git repository
cd existing_repo
git remote rename origin old-origin
git remote add origin git@gitlab.com:my-blog/hugo-site.git
git push --set-upstream origin --all
git push --set-upstream origin --tags
Submodules
I have a website that I generated with static site generator, Hugo. It contains of 3 git repositories, the website, the theme, and the content directory. How would I combine that, so I could host it on Cloudflare Pages? I want to use git submodules.
Add
To host your Hugo website with Cloudflare Pages and manage the theme and content as submodules, here’s a step-by-step guide:
Initialize a New Repository: In your main Hugo website directory, initialize a new git repository if one doesn’t already exist.
git init
Add Theme and Content as Submodules: Add each repository (theme and content) as a submodule within the main Hugo project. Here’s how:
git submodule add <theme_repo_url> themes/your-theme-name git submodule add <content_repo_url> content
Configure Hugo for Submodules: Ensure your Hugo configuration (e.g.,
config.toml
orconfig.yaml
) is set to point to the theme directory:theme = "your-theme-name"
Commit and Push to GitHub: Stage and commit all changes, including the submodules.
git add . git commit -m "Set up Hugo site with theme and content submodules"
Then push to GitHub (or your chosen Git hosting provider).
git push origin main
Set Up Cloudflare Pages:
- Log in to Cloudflare Pages and link your main Hugo repository.
- In the build settings:
- Build Command:
hugo
- Output Directory:
public
- Environment Variable (optional but recommended):
HUGO_VERSION
set to the version you’re using (e.g.,0.115.3
)
- Enable Submodule Support in the Cloudflare Pages build options so that Cloudflare pulls in your theme and content submodules during deployment.
- Build Command:
Deploy: Cloudflare Pages will now deploy your Hugo site with the submodules automatically, keeping everything in sync with the main, theme, and content repositories.
This setup allows for independent updates to the theme and content repositories, which you can pull into the main site as needed.
Trigger Deploy
Will the site be deployed on updating (git push) any of the repository?
No, Cloudflare Pages will only trigger a deployment when changes are pushed to the main Hugo repository, not when you update the theme or content submodules separately. Here’s how to handle updates for those:
Update Submodules Locally: When you make changes in the theme or content repositories, pull those changes into your main repository:
git submodule update --remote --merge
Commit the Submodule Changes: After updating the submodules, commit the changes in the main repository.
git add . git commit -m "Update theme/content submodule" git push origin main
Trigger Deployment: Pushing this commit to the main repository will trigger Cloudflare Pages to redeploy the site with the updated submodules.
Alternatively, if you want to automate this process further, you could consider using GitHub Actions or a similar CI/CD tool to pull in submodule changes, update the main repository, and push a commit to trigger deployment.
No need for .gitignore
Should I add these submodules directories to the .gitignore file, or is it handled automatically? I mean, when I do git add –all and pushing it to my repository, will there be conflicts? Won’t I push to the other repositories as well? Or is this situation handled automatically?
You don’t need to add the submodule directories to .gitignore
—Git manages them separately from the main repository files. When you use git add --all
, Git will only track the submodule references (essentially a pointer to a specific commit in each submodule repository) instead of adding the actual files from the submodules.
Here’s how Git handles submodules in this situation:
Submodule Directories as Pointers: When you add or update submodules, Git records the commit hash for each submodule in the main repository. This means that, even though you see the full files locally, only the commit references (hashes) are pushed to the main repository.
No Direct Pushing to Submodules: Using
git add --all
and then pushing in the main repository does not push changes to the theme or content repositories. It only pushes the updated submodule commit references in the main repo.No Conflicts from Submodules: Since the main repository only tracks the commit pointers to the submodules, there won’t be conflicts caused by changes within submodule files themselves. Conflicts could only arise if two branches in the main repository are set to different commits for a submodule, but Git will prompt you to resolve this by choosing which submodule commit to use.
Example Workflow for Updates
Make Changes in Submodules: If you update files in your theme or content repositories, commit those changes within their respective repositories:
cd themes/your-theme-name git add . git commit -m "Update theme styles" git push origin main
Update Submodule in Main Repo: After pushing submodule changes, update the reference in your main repository:
cd /path/to/your/main/repo git submodule update --remote --merge git add . git commit -m "Update submodule pointers" git push origin main
Following this approach keeps everything organized, without the need to edit .gitignore
or worry about pushing unintended files.
Well, I decided I don’t want to use submodules this time. As I don’t want to lose the convenience of ssh , and I don’t want to waste my time and/or postpone the project for trying to make the ssh-solution work. I can separate repositories at any time, and I don’t see it as needed any time soon anyway.