I'm on a private project that eventually will become open source. We have a few team members, talented enough with the technologies to build apps, but not dedicated developers who can write clean/beautiful and most importantly long-term maintainable code.I've set out to refactor the code base, but it's a bit unwieldy as someone in the team out in another country I'm not in regular contact with could be updating this totally separate thing.I know one solution is to communicate rapidly or adopt better PM practices, but we're just not that big yet. I just want to clean up the code and merge nicely into what he has updated. Would using a branch be a suitable plan? A best-effort-merge? Something else?
How can I refactor a code base while others rapidly commit to it?
open source;version control;git;refactoring;branching
One thing people often fail to consider is that a clean architecture doesn't only speed up long term maintenance, it also speeds up development right now.  Don't try to insulate your changes from your colleagues until they are done.  Your changes will help them be more productive and less prone to bugs.The most frequent mistake people make when undertaking a large refactor is to not merge often enough, instead trying to do it in one big bang.  The right way to do it is to make the smallest possible refactor you can, test it, then merge it into your colleague's branch, and teach him about the change so he can incorporate it going forward.  Ideally you're doing one merge per day, or one per week at the very least.