What is the Hugo git workflow?

Meta
1

So I just completed a short but very useful class to learn about git and GitHub, covering the typical commands and workflow. I’m curious to know how Hugo does the git workflow, like branches, merging, rebasing, work-in-progress stuff and squashing commits when it’s done…

I took a peek at the branches and if I had to guess, it seems to me the main work happens on everyone’s forks and pull requests are submitted. When they are accepted and merged, it goes into the master branch. Then when it’s time for a new version, a new branch is made from the master at that point with the version number name. Then it’s… merged? as the new stable branch and a release is built on that? And all the version branches are kept for posterity (presumably so one could go back and build hugo as that past version? or… is it just to keep a history?)

I thought there was a way to view a repository tree, like in GitX, just from the GitHub website but I guess there isn’t, I’d have to install a git gui program on windows to do it.

I would think a typical workflow would be to branch off the master when you are starting a new version, and then merge that back into master when you are read, but that doesn’t exactly seem to be the model here.

Thanks for any insight!

1 Like
2

The version branches are kept out of pure lazynes. I will do a spring cleaning. We, of course, keep the version tags.

Quick summary:

Development workflow:

  • GitHub dictates a “feature branch” and then PR workflow. We have a very good CI build/test setup to Windows, Linux and MacOs, which makes me often do PRs even for smaller changes just to get the “green status”.
  • But for bigger and longer running branches the method I tend to recommend is to rebase against master (rebase master) at intervals. This includes just before you create a PR (to make sure it merges easily) and also when you pick up the work on that branch after some time (I have Hugo features that has been sitting in a branch for many months before I eventually finish it, so rebase is your friend).
  • I really recommend hub, a CLI tool from GitHub. You can then do hub fork and hub pull-request etc.

Hugo release:

  • The branching is kind of dictated by the automated release workflow. Which is a Go program I have written that combines Go Releaser with Circle CI 2.
  • So a new “approve workflow” is triggered by a new branch with then name “release-VERSION”
  • Automated release notes are created and committed to that branch.
  • I do some manual edits to those release notes. When done, I rename the file with prefix “ready”, e.g.“ready-releasenotes-0.41.md”
  • This triggers a new approve workflow in Circle CI, which creates binaries, a GitHub release draft and a release tag.
  • When I’m happy, I publish the release and merge the version tag into master + stable (for the Snap build).

There are some manual steps above that can possibly be automated, but I like to have some kind of control, and writing some good release notes is one of the must-haves.

8 Likes