4 ms·
(Not the OP, obviously.) > rebase is not the same as avoiding merge problems. Yes it is. The point is this: Everybody rebases against "what is to become our n
by lomnakkus 12y ago
(Not the OP, obviously.)
> 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.