I have a website I built in Angular a few years ago, and I'm considering a substantial rewrite now that I'm more familiar with React. The core functionality and purpose would stay mostly the same, but much of the implementation would change. Is it better to keep the existing repository and preserve its history, or start a new one? What usually determines whether a project has changed enough to deserve a separate repository?
3 Answers
Changing the framework alone usually isn’t enough reason to create a new repository. Keep the same project history and use a clearly named branch while developing the rewrite. Start a separate repository if the old project will remain untouched, the new project has a different purpose, or the requirements and architecture are changing so extensively that it is no longer really the same product.
Keep the existing repository if it’s still fundamentally the same application. You can create a branch for the React rewrite, keep the current version stable while you work, and merge it once the new version is ready. Preserving the history is usually more valuable than having a perfectly clean repository.
A framework migration is a legitimate engineering task and can be useful experience to demonstrate. Real projects are often migrated from one framework, language, database, or architecture to another while keeping the same underlying product. A new repository makes more sense when the business purpose and requirements are changing so much that you’re effectively creating a different service. In this case, the core functionality is staying the same, so the existing repository fits.
I hadn’t thought of a framework migration as a skill by itself. Is it considered valuable because it involves adapting an existing system rather than simply starting from a blank template?
That makes sense. I like being able to look back at the old commits and see how much I’ve improved, so losing that history probably isn’t worth it. I may treat the rewrite as a major version, such as version 2.0.