The issue that I can't figure out, is how to deal with refactors, or more broadly, a codebase that changes. If my feature takes two weeks to develop, when I'm r

The issue that I can't figure out, is how to deal with refactors, or more broadly, a codebase that changes. If my feature takes two weeks to develop, when I'm ready to merge, I'm applying my changes to a codebase that's two weeks newer than when I branched. For a merge to be not-painful, the master branch should stay reasonably steady. This, I think, creates a conservative, change-adverse culture, rather than a IMO superior "if it's wrong, fix it, fix it right and fix it now"-culture. If I continuously rebase (and especially after a colleague emails saying he's pushed a big refactor), I can fix these things as and when they happen, and I can feed back to my colleague if something they've done works poorly with what I'm working on, and they can then address that while they still have the context of the rebase in working memory. Finally, I think the history criticism is based on a too narrow view of history, as a single, linear reality. My code might have been weeks in the making, and while it's true I wrote that particular function on Monday, if I didn't push it until Thursday, it simply didn't exist in the world of my peers until then. Merging history so something I wrote on Monday appears as having existed on Monday, even though it didn't and couldn't affect the world until Thursday is also dishonest.