Ensuring that branches are useful and not "cluttering" requires a bit of discipline. It's easy to get a bit branch-happy in which case you end up with changes scattered across a number of branches that may or may not have a consistent starting point. This will cause issues when you have to merge all the updates for a release.
A general rule of thumb is only to create a branch when you need to work in parallel: code needs to be separated to allow for simultaneous updates or if a feature needs to be isolated until it's release timetable is set. This will vary depending on team size, work patterns and the nature of code changes.
Comments
Ensuring that branches are useful and not "cluttering" requires a bit of discipline. It's easy to get a bit branch-happy in which case you end up with changes scattered across a number of branches that may or may not have a consistent starting point. This will cause issues when you have to merge all the updates for a release.
A general rule of thumb is only to create a branch when you need to work in parallel: code needs to be separated to allow for simultaneous updates or if a feature needs to be isolated until it's release timetable is set. This will vary depending on team size, work patterns and the nature of code changes.