‹ start

🚀2019.240

Unless you have opinions about version control, you will not get much from this post.

Introducing GitYolo flow🔥.

I think this 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 ready to deploy and it’s always up to date with the latest dev work.

Never 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 almost all of my work. Personal branches should be merged often, rebased often and should never diverge far from the project branch.

Code reviews happen after merge. The changes after someone says “please make these changes” are made in a new PR. PR titles should be descriptive with a team audience in mind.

For branches that do need to live a little longer, GitYolo recommends snapshots. They should be prefixed with snapshot/.

  • snapshot/v1.0.0
  • snapshot/spike_4

Finally, GitYolo does not recommend linking Git commits to project 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.