Let's say we are using TDD while developing some Calculator class (the simplest case - it should provide add, sub, mul and div public methods). We initially start with develop branch. The following patterns come to my mind:

Pattern 1:
At the beginning we would be able to add numbers. We create feature-add branch and do typical TDD flow. At the end we have fully implemented and tested functionality so we merge current branch with develop. Next subtracting should be implemented - new branch called feature-sub will be created, TDD cycles will be done and feature-sub branch will be merged with develop. The same workflow would take place when implementing mul and div methods.

Pattern 2: We create feature-operators branch. All the code and tests for above functionalities should be done inside single branch (they are logically "one piece" of code)

Is it better to have one bigger branch or many small branches that join one TDD functionality (e.g. one public method)?

  • 3
    Are you actually collaborating with anyone on this? What's the purpose of the branches? – jonrsharpe May 5 at 18:17
  • Do you even need these feature branches? Unless you're doing pull request reviews, it would be much faster and easier to practice Continuous Integration (in the original sense) and commit to the main branch directly. Just make sure to never git push broken code. Effectively, your locally checked out repo is a branch anyway. Also check out Martin Fowler's collection of Branching Patterns which covers various approaches. – amon May 5 at 19:31

It's generally accepted that its better to have "shorter lived" branches.

The logic is that while you are programming away on your branch, someone else is checking in changes to master. When you finish, you will have lots of merge conflicts and be making a large risky change. Additionally everyone else with a branch in progress when you do your merge will have to encorporate your changes into their branch. Lots of work all round.

If however, you check in multiple branches over the same period of time, each one will be a smaller change, easier to review and easier to encorporate into other branches.

We should also not forget the project management aspect to multiple merges. If you spend 4 weeks programming all the features and then merge for 100% completion, your project manager will have an angst ridden 4 weeks and you will be the hero rockstar programmer who saved the company when you finish everything just in time because you worked late on your secret branch with no timestamps on the checkins

If you check in 1 feature every week, your project manager will be able to draw nice graphs saying you are 25%, 50% etc done and predict the launch date, organise the big demo party and generally succeed at their job while you churn out code unthanked in a darkened basement. So you know, plusses and minuses

| improve this answer | |

Is it better to have one bigger branch or many small branches that join one TDD functionality (e.g. one public method)?

Test Driven Development/Test Driven Design are branch-strategy agnostic. You can do feature branches, or trunk based, and the red-green-refactor protocol just keeps chugging along.

For evidence about branching strategies, the reference you want is Accelerate (Nicole Forsgren et al). Chapter 4 talks discusses their conclusions about technical practices, including Trunk Based Development:

Our research found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance. Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into trunk and never had a "code freeze" or stabilization period.

| improve this answer | |

It depends on the size of the project versus the size of the individual feature, and in some respects the number of other developers working in the same codebase.

In the example you describe, if Calculator has many other methods and associated classes, then perhaps feature-operators would be appropriately sized.

However, if Calculator is the only class you have, and has just 4 public methods, then that same feature-operators branch would be too large, and feature-add would be a better approach.

No matter the size of your branch, it's important to continuously update your local branch with the latest version of develop, so you can make adjustments based on already committed changes.

Incorporating the latest version into your code will dramatically reduce the number of merge conflicts in your own changes.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.