Manage a Re-write with Git

I have a project, the source of which I'm managing with Git. It's a big project--relative to my experience--and I feel like I will completely re-write at some point after its completion. Though this is a problem I won't encounter for a long time, I'm curious: how would I manage a complete re-write with Git?

Would it be best to make a completely new repo to manage the code? Or perhaps bra开发者_如何学运维nch my WC and re-build inside there? Though it probably depends on specifics (e.g. how much code will be re-written, will I want to be able to reference old files or lines of code), what would be the best way to handle this? For generality's sake, let's answer those two questions: Imagine a complete re-write, but with lessons learned from the 1.0 build, if you will.

I hope that makes sense. Let me know if you need more clarification. Thanks.

---

This depends on how you are planning to do the rewrite. It you really are throwing everything away and rewriting completely from scratch, then perhaps starting a new Git repo would be a good idea. But I wouldn't recommend that; there's probably a lot of good knowledge (tests, documentation, bug fixes for odd corner cases that most people don't think of at first, and so on; as you say, lessons learned from 1.0) embedded in the old implementation that you want to retain in the new one.

So I would recommend working in a branch, or cloning the repo and working in the clone. It may even be a good idea to try doing the rewrite as a large scale refactoring, rather than a rewrite from scratch. Try to keep as much code working as you can in the process of rewriting it, never going too long with anything broken or major functionality stripped out. You'd be surprised how working from the old code base and just doing a large scale refactoring, where you're careful not to break stuff that's working, can be more efficient than a ground-up rewrite. A ground up rewrite frequently gets you something that seems to do 90% (using standard, pulled out of thin air statistics of 90/10) of what the old one did very quickly, and much more clean/fast/new/shiny/whatver, but then you discover that that last 10% is critical and actually a lot harder than you thought, and you realize that bugs that you fixed long ago in the old system have cropped up again in the new one.