Rebasing regularly is a task that requires diligence, skill and good communication. I've built solo "out-there" feature branches that I've kept alive through c

Rebasing regularly is a task that requires diligence, skill and good communication. I've built solo "out-there" feature branches that I've kept alive through careful rebasing for more than a year without issue - but once you're working on a team absolutely everybody must be onboard with the strategy for it to work... as soon as people go off on a garden path doing unnecessary refactoring[1] in a big long-lived feature branch you start into the world of pain - refactors (especially code movement within a file like function reordering) lead to all sorts of unnecessary chaos. If you're going to make a long lived feature branch you absolutely need to KISS[2] - the smaller your change set the better your chances of avoiding having a bad time. 1. IMO refactoring is one of the best things you can do for your codebase but it should NEVER happen in a branch that may be blocked from merging for other reasons - keep refactors in isolated branches if there's any danger of your merge being delayed for any reason other than an issue with the refactor. 2. Keep It Simple, Stupid - i.e. avoid any complexities not absolutely necessary for the feature.