| > You never push incomplete work while intending to continue it the next day... maybe on another machine? Nope. I wouldn't want to switch machines halfway through a change that left the code broken. I'd either get to a point where it was working, or just not push. (Being able to break changes down into small pieces while keeping the codebase working at all times helps, but that's a good skill to develop anyway - it makes automated bisection in the future much more effective). > You never run across build failures on other machines when everything builds fine locally? You never see bugs that don't repro locally? You never trigger or re-trigger tests to narrow down bugs you can't repro locally but know to exist? Every single commit you push can be assumed to build on everyone's machines, pass all tests, and provide a proper foundation to branch from? And these are all true for everyone you work with too? Occasionally you'll hit a transient or machine-dependent bug, sure. (That can happen in master too, though it's less of a risk). But again, it's not a big deal when that happens. If you discover a bug in someone's branch then that is a situation that's worth interrupting them to talk about. You coordinate, they fix it and you pull their branch again - or you fix it and they pull your branch. Most likely you need to communicate and collaborate on the fix in any case, since you know what the bug is while they know what their changes were. There's a cost and a risk associated with working with code that hasn't yet passed all of the master gates. But there's also a cost and a risk to working on a particular code area without seeing your coworker's changes in that area, even if they haven't gone into master yet. Most of the time the tradeoff works in favour of pulling their branch, IME. |