Skip to main content

A tale of long-living feature branches and why to avoid them

·264 words·2 mins
Grzegorz Kocjan
Author
Grzegorz Kocjan

Work in progress

Once upon a time, in December 2022, two talented developers, named Grzegorz K. and John D., met after a daily meeting with their team. They were tasked with developing a new feature. Little did they know, the decision they made that day would change their lives for the next two months.

The project was going well in the beginning. Grzegorz and John were working hard, coding using TDD, and making progress every day. But as time passed, the complexity of their code grew, and the number of dependencies increased. They started to feel the weight of their decision, and soon, the project turned into a nightmare.

Git merge conflicts became a constant occurrence, causing frustration and delays. The pressure of the project was starting to take its toll on them.

Then, the big bang release arrived. The feature was finally ready to be deployed to the production environment. They worked tirelessly to fix the last few bugs and ensure everything was ready. The whole deployment took two weeks. The once-exciting project had turned into a hellish experience for the two developers and any other individual who was dependent on the incoming changes.

If only Grzegorz and John had known what was to come, they would have tried to avoid the decisions that led them down this path…

… but you can learn from their mistake and don’t follow this path. At the presentation, you will learn how bad it is to create long-living branches and how to work with frequent small releases that don’t break anything and what’s most important fun to code :)



comments powered by Disqus