Tutorial: How to use Git in a team development environment

I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler. [1] https://trunkbaseddevelopment.com/

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't seem to pass CI). The time between code…

This was terrible at the time and it remains terrible now. Extremely few teams need this level of complexity and some parts of it – like the redundant long-lived develop branch – are pointless safety blankets. It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is. I’ve seen so many small teams tie themselves up wasting time working for Git…

Over time, I have come to feel this git workflow is more of an attempt to coerce git into a workflow that is familiar to users coming from subversion, rather than learning and understanding git's strengths. A corollary problems is that it mixes development workflow with release management - two disparate concerns that should be handled separately. After a couple years of using this model, I have done away with using a develop or release branches whatsoever. Develop everything in…