I haven’t written about my Git workflow for over a decade. The last time I documented my Git workflow was during a contract. I needed to explain Git to a new employee who was new to development.
My perspective
I’m writing this post based on my experience as a solo developer. Unless I am in a contract, I spend much of my time working solo. There is no reason these workflows won’t work with small or larger teams; your results will vary. With larger teams you don’t get a choice though as the organization decides what is best.
Project Type
The type and state of the project maters. When the project is in the initial stages of development and there hasn’t been a release, everything happens in “main”. A release could be the first alpha release for testers, the initial preview for a client or just the point that feels right. If the project is past its first release, the only question that matters is, public or private repo?
If the project lives in a public repository, all my development happens on a fork. The fork is effectively my feature/dev branch. I will merge back into “main” as often as possible. I will merge when a specific feature is complete, when a bug is fixed or just when it feels right. My work on Budget is an example of this, I have a fork and never commit directly into the “main” repo.
When the project lives in a private repository, all my development happens on feature branches. Where possible these are small feature branches. We all know that sometimes you are going to have the long-lived feature branches, in those instances I will merge main into the long-lived feature branch anytime “main” changes. Budget Pro lives in a private repository so there is no fork, just the main repository.
Feature branches
Whenever possible, yes, small feature branches are the way to go. The only real change in my approach is where the feature branch lives, is it a fork or a branch off “main”.
There are exceptions, there will always be edge cases. Edge cases are different for all of us, you know yours. If your edge cases are rare, it is ok to break the rules occasionally.
If you got to the end of this post and are wondering, well, that seem simple, yes, that is the point. Our work is hard enough, we don’t need to complicate it by adding unnecessary steps to our development processes.
I have avoided talking about continuous integration and continuous delivery in this post, they are topics for a different day. Our first priorities should be making development easy and ensuring “main” is stable.
This post is a continuation of a series in which I talk about me development process. Please check out some of my other posts, my typical project setup and action class usage in my Laravel apps.