> Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They

> Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser. We actually use SVN. It is considered negatively impacting on communication to have work hidden on local DVCS branches instead of immediately visible to the team upon commit. This requires one to commit often, in very small chunks, while driving from a test-first perspective. In the cases where that isn't possibly (highly experimental work), a branch will be used. > But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point. Inadequate unit test coverage or missing documentation would be considered a serious offense here. The only code that winds up being difficult to capture in unit tests is usually GUI code (or in the case of web development, the HTML/CSS front-end bits). The testing and validation of those pieces happens outside this process, usually driven by basic automated integration testing and the watchful eye of the design department. The UI code is expected to be minimal and only involved in the UI. All significant work occurs in the testable backend code. > I wonder, where in your process does code review come in? After commit, diffs on the mailing list are reviewed, but not formally. If someone thinks something needs another set of eyes, they ask explicitly.