GitLive flow
A trunk-based version control strategy
Version Control
In software development, keeping track of your code — additions, deletions, changes — is crucially important. We call this versioning. I have noticed three significant eras of versioning in the 15 years that I’ve been developing software.
The first was called Git Flow, it was all about careful progression through different stages of code approval, it was robust but also involved a good deal of bureaucracy.
The second (still very common) strategy is called Github flow, where the fundamental unit of code is a feature. The careful code approval happens on a per-feature basis — before each feature goes live.
The third and latest era is Trunk Based. It’s still generally used in a feature-centric way but it introduces this new convention of release branches. It’s a significant change. Previously, the master branch was the same as the production branch and it meant that master could never, ever be allowed to break (or else the users would suffer). Master was sacrosanct.
Trunk based is a really nice way to work and is becoming widely adopted.
GitLive Flow
GitLive flow is a version control strategy that adapts Trunk Based for more realtime collaborative work between remote teams. It assumes there is constant real-time communication between all of the currently active developers inside a group chat (Slack, Microsoft Teams). Ideally, they should like working together and enjoy each other’s company.
A dev should write a little bit of useful code (a “micro change”) in a dedicated branch and merge it into master (approving the merge themselves), at which point a link to the PR is posted to the group chat where the other team members prioritise reading it. The team should chat about the PR, ask questions, hit it with a thumbs-up or a dancing dinosaur emoji. That’s it. It’s still being reviewed, just not being previewed. Any requested changes can happen afterwards.
PR =!= Feature
GitLive flow actively discourages the convention of one PR for each feature. Pull requests should be smaller and more frequent, features should be merged into master incrementally and in stages.
Discussions about form and strategy happen earlier, more collective decision-making, happier and more collaborative teams. Write, merge, chat. Loop it, get the pace up, hackathon style. Do it live. People working on the same feature together at the same time, why not, go crazy.
Features over on the kanban board can still be fully present and accounted for. PR’s can still reference tickets but each feature will now have a few PR’s attached instead of just one. I don’t think that’s a bad thing at all, a unit of feature is rarely the same thing as a unit of code. They’re different abstractions and a mandatory tight coupling isn’t always helpful.
Branch Names === Dev Names
Branch names should be created for each developer on the team. I do all my work in the Dom branch, I sync it with master often. Bob and Alice do the same. After merging your branch, delete it. It will be be recreated again automatically when you do your next commit anyway. That’s a good time to take a break from the screen. My branch exists when I’m working (when I’m live) and it doesn’t exist when I’m not. And at the end of the coding session, when the devs do their final merge for the day and log off — there’s just master, standing alone, impeccably up to date and ready to have a release branch cut and tested whenever needed.
GitLive flow does not have to be a primary version control strategy, it can be used in conjunction with other strategies, dropped in and out of. It’s Git for teams to experiment with active coding sessions on real world codebases.
