I was interested to read Sam Marshall's post, saying:
On the other hand, because of the way Moodle development works there is a huge gap between 2.7 and 2.8 development during which the code will rot and this will make significant extra work...
We've discussed the nature of the code freeze and on-sync periods internally in the Integration team and I've never been convinced that it is a significant problem to change process. In fact, I see the ease of branching and the git tooling for maintaining branches one of the main advantages of moving to git and I don't think a long-lived feature branch is problematic. 
To quickly outline the current process, as it will happen for Moodle 2.7:
- We will stop accepting changes/new features for 2.7 - call it Week 1
- For a month we will do Quality Assurance and polishing on the release
- On the day of release of 2.7, we branch for MOODLE_27_STABLE - Week 5
- For 3 weeks after the release we keep master and MOODLE_27_STABLE the same (we call this the on-sync period)
- Week 8 - New features again start getting integrated to master
Now you might think - this is 2 months where your code is sitting on a feature branch rather than in master, of course thats problematic.. but:
- It keeps our resources focused on making the best release possible. That means not having an integrator or tester tied up in reviewing and testing a huge change which is for a future release.
- The changes going on in master should only be bug fixes, so the 'bit rot' should be limited. (Though it should be acknowledged that our discipline about code freeze has been less than ideal and is something we are committed to become much tougher on this release).
- It reduces the amount of conflict resolution work developers working on the 'current' (say 2.7) release have to do. In fact it moves the problem of conflict resolution to the 2.8 developers.
- I think it sets the tone of our focus as a development community. This might not be easily quantifiable, but I think its helpful that everyone is clear what our focus is and why we are not dealing with future changes at the time.
Note there are many other ways we could conduct development... Some examples:
- We could branch at code freeze (point 1) and immediately start accepting changes for 2.8. I am really unconvinced of this approach, because I know what drain on resources it would be. I think it would diminish from the quality of the release.
- We could abolish the on-sync period. I'm not especially against this idea, but I don't think those 3 weeks make a huge amount of difference.
What have been your experiences been and what do you think?
 I am very comfortable with git though