Question how to manage code efficiently from rerunning of swagger-codegen ?

Description

My service api model with swagger api spec is not completely fixed yet.
So, I sometimes change my api model with yaml file.
After this api model change, Of course I rerun the swagger codegen cli to generate all codes to apply the api model change.
Issue appears from the second code generation.
I have already touched implementations on the service and controller Stubs which are generated by swagger-codegen.
So, newly generated code overwrite the existing code. :(
Luckily, I manage my code with git, so I could see the differrence of git code and changed code.
But, I should merge the difference by my self for now.
Of course, I found the .swagger-codegen-ignore file, but for the implementation added files, it's useless and can't avoid file dump caused by swagger codegen.

Swagger-codegen version

swagger-codegen-cli-2.4.18

Swagger declaration file content or url

issue is not related with swagger file by itself.

Command line used for generation

java -jar ./tools/swagger-codegen-cli.jar generate -i ./api/ar_service_api.yaml --ignore-file-override=./swagger-codegen-ignore -l nodejs-server -o rest

Steps to reproduce

1. generate api mode by following swagger spec
2. generated stubs by using swagger codegen cli for the first time
3. touch the implementation to the stubs under service
4. change the api model on the 1)
5. re-generate stubs by using swagger codegen cli
6. I could see the stubs which are updated through 1) -> 3) are dumped by 5)

Related issues/PRs

no related issue and PR.

Suggest a fix/enhancement

Can I get the best code management strategy or practice / guide with swagger-codegen ?

And, What if swagger-codegen cli will apply code diff ?
is it possible to the code diff when swagger-codegen is rerun and code is managed with git or github ?

Start with the documented swagger-codegen CLI generation command, the generated service and controller stubs, and the .swagger-codegen-ignore behavior described in the report. Determine whether the project has an existing entry point or guidance for preserving implementations across regeneration; done would require a documented strategy or a clearly scoped, agreed approach for rerunning generation without losing changes.