Nobody wants to review a PR with 100s of files, nor is it nice to have a lot of work that is committed (a PR may even be waiting), but not approved. This is merge debt. Part of getting work complete is getting the PR approved by another developer so you don’t have it sitting around for a long time.
The default option is to use a feature branch strategy which is awesome for small chunks of work. However, if you know that your work involves 2+ devs working on different tasks and they cannot work in isolation, then it can be tricky. For example, if you need to migrate from Gatsby to Next.js or if you have to upgrade from Xamarin to .NET MAUI then a feature branch strategy might not be appropriate. In that case choose from the below options:
This is a good option if you are concerned with legacy technical decisions impacting the future application.
Figure: Good example – Developing the new application in a new repo
In this scenario you will be replacing the old project (folder) at the end for a final rubber stamp PR
This is a good option if you are not worried about the legacy application influencing the new application.
Figure: Good example – Developing your new application in a new folder