The Hubbish Flow?

My need has been for a workflow adequate for a sole developer and that takes as little work as possible to follow. That last bit is lo más importante for me; if I find it tedious and lack a requirement from being in a team, I’ll let it fall by the wayside and be back where I started.

After considering various pros and cons of a number of existing workflows, I came up with a tweaked version of the GitHub Flow that it seems would work the best for my purposes. Call it the “GitHubbish Flow” or just the “Hubbish Flow.” Professional developers might think it an undesirable approach, but it’s described below on the off chance that someone else might find it useful.

Assuming use by a sole developer, the Hubbish Flow goes like this:

  1. The main branch is a development branch to which only merges from feature branches are made.
  2. To work on something new, create a feature branch with a descriptive name (e.g. new-oauth2-scopes) branching off from main.
  3. Clone the feature branch separately to your local machine (git clone --single-branch --branch <branchname> <remote-repo-URL> <remote-repo-name.branchname>).
  4. Commit to the feature branch locally, and regularly push your work to the same named branch on the server (git push origin <branchname>).
  5. When the feature branch is ready for merging, open a pull request.
  6. Merge the pull request into main (i.e. don’t use “squash and merge” or “rebase and merge”), and delete the merged feature branch.
  7. When the main branch reaches a desired release point, tag the release point to create a release.

A “feature” may be an actual feature, a bug fix, or any other conceptual aspect of a project. And, of course, multiple feature branches may exist simultaneously to facilitate parallel feature development if desired.

Using the main branch for ongoing development rather than immediate release, and instead tagging particular points as releases facilitates relationship of feature groups with releases. That is, you can say things like, “Version X has new features A, B, C, D, and E.”

Separately cloning feature branches prevents following through on any impulse to commit something directly to the main branch.

The use of pull requests and merging performs merges using the no-ff option, creating a merge commit along with the code commits for each merge. While some consider such commits to be redundant clutter, they provide direct access to their associated code commits, even if the code commits in the full history are interleaved in time with those from other merges. When viewing the repository, the merge commits may then be listed separate from the full commit history by clicking Pull requests, or by searching Merge Pull Request and clicking Commits on the search results page. The search results page provides more information in the resulting list than the Pull requests page and conveniently groups merges from same-named branches together in the list; it can be useful to save a bookmark to the search results page to easily access the list when needed.

Finally, deleting feature branches after merging just avoids clutter, and isn’t worrisome since a branch can always be restored if needed.

In Need of a Workflow

As an individual developer, I’ve been using GitHub — to quote a Software Engineering post — “very simplistically: no branches and basically just using the commits as a backup to my local files.” Following that path, the plan today was to commit completed Chess Opponent throttling control code with a hardcoded throttle value, to replace the hardcoded value with one or more options to set the throttle value, and then to commit that as well. The separate commits were to make rolling back to the working hardcoded version if I mucked things up with the options.

I realized, though, that it’s probably not best to continue that way, committing features to the main line of the code in a piecemeal manner with other little tweaks and bug fixes sprinkled through to confuse things further, and I finally got fed up with having everything in such a disordered state. So instead, of committing anything right now, I’ve decided to take a few days and try to establish a reasonable workflow to make things clearer and more organized from this point on.

While poking around for info on GitHub-applicable workflows, I’ve collected a few items to mull over that might be of interest to others:

The plan now is to get a workflow established in short order and get on with development in a more organized manner going forward. Should be easy, right?