У тебя есть четыре базы пользователей и три метода входа/регистрации. Гора логики! Теперь нужно добавить еще один тип пользователя и убрать одну из старых баз.
Традиционный подход: делаем git branch, работаем, устаем, тестируем, затем merge & pray.
Окей. Но что если нужно вносить изменения постепенно, и какое-то время поддерживать старые варианты на период миграции? Или другой кейс: если участок кода настолько критичный, что его должны внимательно просмотреть несколько человек?
Есть другой подход. Вместо merge и безжалостного кромсания я пишу новый код на месте, оборачивая его в if. Во-первых, можно оборачивать в if (0) или if (isNew) — так код будет компилироваться и валидироваться, но не выполняться (я когда-то писал об этом). Сломается продакшн — можно очень быстро понять что сломалось и очень быстро откатить. Легко проверять тестами. Мелкие изменения существенно безопаснее, чем один большой апдейт.
Во-вторых, при таком подходе получается более понятный diff. Причем не только по каждому конкретному коммиту, но diff между нетронутым и новым кодом: сразу в одном экране будет и старая и новая ветки кода. Удобно для review.
Какой подход правильный для какого случая? Тебе решать.
PS: Запомни: git diff --ignore-space-at-eol --break-rewrites --ignore-all-space --ignore-blank-lines