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