Java Pills

• Do you want to keep your branch history clean and effective?
• Are you part of a development team of at least 4-5 people, looking for a structured but agile workflow?

🕐 Reading time: 3 minutes

In my team we adopt a variant of Git Flow, with influences from Trunk-Based Development (TBD), optimised for Agile methodologies. This approach combines organisation and flexibility, improving the development and integration process. In this post I'll explain our strategy.

📌 A Git repository structured on four levels

• master: holds the stable code, production-ready
• develop: collects the candidate versions for the staging environment at the end of the sprint
• sprint: a temporary branch used during a single release cycle in the testing phase
• feature/fix: branches dedicated to single features or fixes, integrated into the sprint branch via squash merges

📌 Merge strategy

• merge from parent to child (master → develop, develop → sprint, sprint → feature)
• squash merge from child to parent, so as to keep a cleaner history
• the feature/fix branches are forked off the current sprint branch. Before running the squash merge towards sprint, it's a good idea to "pull in" the most recent changes from the sprint branch into your feature, resolving any conflicts ahead of time
• at the end of the sprint, its branch (S) is merged into develop via a squash merge. The sprint branch is then archived and a new branch (S+1) is forked off develop for the next sprint. The feature/fix branches linked to the completed sprint are deleted, thus preserving the necessary granularity while discarding superfluous details

📌 Advantages of this hybrid flow

1. parent-to-child merges ensure branches always inherit the latest updates
2. constant alignment avoids large conflicts at the end of development
3. any conflicts are resolved in the child branches, keeping the parent branch clean
4. thanks to the squash merge towards the parent branch, the main history isn't weighed down by intermediate commits
5. you keep a clearer, more linear log, useful for debugging and rollbacks when needed
6. the team can work in parallel on independent features
7. alignment with continuous integration (CI/CD)
8. suitable both for teams doing frequent releases (TBD) and for those working on more structured sprints

🔍 Conclusion

This hybrid model between Git Flow and TBD turns out to be particularly effective in an iterative, sprint-based development context: it provides structured control over releases and, at the same time, a leaner management of features and merge strategy, in line with the principles of continuous integration.

📩 Get in touch if you'd like a more detailed guide!

See you at the next pill! ☕