🔥 GitYolo flow.
Unless you have opinions about version control, you will not get much from this post.
Introducing GitYolo flow🔥. It's a version control strategy and I think it could work well for small teams doing fast Proof of Concept work.
GitYolo flow is centred around a single branch, the project branch. It should have the same name as the repo (we’re going to retire the word master). The project branch is always up to date with the latest dev work and is always ready to deploy.
Don’t break the project branch.
With GitYolo, every forked branch is named after the individual that forked it. My branch is called Dom, it’s where I do my work. Personal branches should be merged often, rebased often and should never diverge far from the project branch.
Code reviews happen before merge (teammates should hop in and test each other’s branches) but non-critical changes should happen after the merge, if the code generally works and isn't explicitly breaking something, get it in first then improve it in a new PR.
For branches that do need to live a little longer, GitYolo recommends snapshots. They should be prefixed with snapshot/.
GitYolo does not permit linking Git commits to project management tickets, they’re two completely different levels of abstraction and forcing a tight coupling impairs them both. GitYolo is intended to be a stepping-stone in our transition from turn-based to real-time software development.