rebase is not the same as avoiding merge problems.
what does it help you if you and other dev have their, often rebased or not, branches for a long time? the first one will be fine, second will have merge hell.
honestly, you are only comfortable with that setup because you probably work alone on a small team.
edit: and dont get me wrong, if that is the case, you are using the right tool for the job. i would love to be able to not rely on regular atomic commits in my huge dysfunctional group.
> rebase is not the same as avoiding merge problems.
Yes it is. The point is this: Everybody rebases against "what is to become our next release" on a continual (daily if not more frequent) basis. If you have acceptable levels of unit testing and integration testing on your feature branches there's usually no problem with early (that is, way before the sprint ends) merging of feature branches to master. If your team is really paranoid and all your team's feature branches tend to pile up until the last day of the sprint[1], you could forcibly (via process) stagger your feature merges so that they're always at least 1 day apart to catch any bad interactions between features.
[1] This is indicative of other problems to do with process/management, so take the next bit of advice with a grain of salt.
what does it help you if you and other dev have their, often rebased or not, branches for a long time? the first one will be fine, second will have merge hell.
honestly, you are only comfortable with that setup because you probably work alone on a small team.
edit: and dont get me wrong, if that is the case, you are using the right tool for the job. i would love to be able to not rely on regular atomic commits in my huge dysfunctional group.