[brown9-2]

The alternative, having everyone work on the master branch, is a bigger drag, because it introduces all sorts of coordination problems like "is the master branch in a state to be deployed? are your changes done?".

[sidcool]

You are right, that would be the opposite extreme. What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production.

This saves us some merging.

[brown9-2]

Is merging painful enough for you team that it's worth avoiding?

[sidcool]

It can't be avoided, but we do tend to try and minimize it.

[fishtoaster]

My experience has been that maximizing merges works best. If you're constantly merging, hardly any of your merges have any friction. The longer you're separate from the master branch, the more likely you are to get painful merges with conflicts and subtle bugs.

[erichurkman]

Elsewhere in the thread, you'll see that 'sidcool is on SVN, where merging is not a fun experience — which explains his team's aversion to merges.