Well, if you're running a development tree, it isn't eligible for inclusion into linux-next,
since linux-next only consists of everything that will go in in the next merge window. What
you'd be developing this way is a patch series being posted to a mailing list and refined.
Once it's ready for inclusion, and everyone's signed off, then you get your own tree or send
them to a subsystem maintainer (and usually the latter if you have conflicts against linus
because you need to go through the tree of the subsystem you're in conflict with).
With this method of development, you can be targeting 2.6.n+1 since the delta between linus
and linux-next goes to zero within the merge window.
The whole point of developing against linux next is to see where you do pick up conflicts. If
you do and you don't resolve them (which the rebasing method allows you to), Linus is hardly
going to choose to merge your tree over the subsystem tree you just conflicted with. It's far
easier to resolve conflicts incrementally (as in daily) than wait for weeks and see how bad it
becomes (believe me, I've done both).