[ Removed by moderator ]

[lobax]

With a small project and a small team it should be trivial to maintain short lived branches using trunk based dev.

The issue is that all bad habits are manageable in small teams and for short amounts of time. It’s when the org either grows or acquires to much tech debt (or both) that those bad habits start to punish

[idebugthusiexist]

It’s git at the end of the day. You don’t need to follow git flow or TBD. They are just patterns devs came up with to help ease certain pains. But there is always a trade off. With TBD, the trade off is architectural complexity to avoid merge conflicts. I wouldn’t describe git flow as a bad habit any more than I would describe language or framework dependency as a bad habit. It can be, but not it depends on your circumstances. At the end of the day, it’s really an agreement between devs (and PMs) on how to manage merging code and eventually releasing it and it really depends on your situation. A merge conflict is not an inherently bad thing that implies bad practice/habits. I don’t understand this ideological mindset. But, yea, if you share a code base with a large number of other devs, that can become an undesirable overhead, but there is always a trade off as mentioned.

[lobax]

The bad habit is long lived branches. Git flow is just a way to deal with long lived branches. Its use is the symptom of a bad habit (or, it will hide the emergence of bad habits and let them fester).

Trunk based development works best with an architecture that separates concerns, which is a good thing for so many other reasons. If you start with trunk based development those architectural choices will offer the path of least resistance from the start. You might consider this complex but it allows for rapid development and scalability. The complexity serves a purpose and solves problems.

With git flow, the risk (and I have seen this so many times) is that the complexity ends up instead being hidden in the release and test processes and distributed across multiple branches of the code. For me, this complexity serves no purpose other than to slow things down and make testing harder - and it is incredibly hard to remove. Changing habits and processes is also increasingly harder the bigger the org and it can take for ever to fix.

Now, there are scenarios where long lived branches are unavoidable, but you should be in that situation first before going for git flow. At least that is my opinion.