For a long time I largely ignored branches in git when working on my own.
Quite frankly, as a solo developer I saw no benefit. I understood gitflow and its brethren but it looked like more work for me and no benefit. (again, as a solo developer, I have recommended it to many teams). I just created feature branches when there was a clear benefit.
Recently though, I’ve been looking to up my automation game. For a while now, I have had all commits to my repo for projects run through tests and builds. But I’ve always had a manual release process which had a number of small steps.
I can automate the release processes but I don’t want it to attempt to release every build. I also wanted a place for checks to take place before the final step.
When looking to automate this I realised the same concepts that apply to a team of people, apply to me and my trusty build server. Hence, my adoption of branching.
My Current Solution
What I do now is (mostly) follow a gitflow pattern. I’ve based it on gitflow because it matches my style of software release. To understand why I have added this caveat, check the notes of reflection on the original article at A successful Git branching model » nvie.com and consider how simple you can make it (like GitFlow considered harmful | End of Line Blog).
Once I have a release candidate on develop, I create a merge request to my released branch. (I’ve got no use for released branches right now)
This merge request gives my usual build checks and then I have a checklist covering anything manual:
- Have I updated the user documentation?
- Have I updated the version numbers in the VIs (soon to be automated)?
- Have I run a complete system test?
- Have I tested this with the end user?
Once I approve the merge request, the CI scripts can detect a merge to the released branch and will build and publish the installers. I’ve also got it making the release tag in Gitlab for me.
So remember, robots are team members too!