I'm currently preparing to leave my company and writing extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution, etc. by myself. So nobody else has any idea what and how things work. I am/was also the only developer in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. I have been using Git for my work there for the last three years. How can I properly encourage whoever is working on the project to continue to use Git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, and hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use Git. Of course the documentation would include a chapter on how to use Git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-safe.

But I don't really know how to motivate a non-developer. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.

I'm currently preparing to leave my company and writing extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution, etc. by myself. So nobody else has any idea what and how things work. I am/was also the only developer in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. I have been using Git for my work there for the last three years. How can I properly encourage whoever is working on the project to continue to use Git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, and hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use Git. Of course the documentation would include a chapter on how to use Git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-safe.

But I don't really know how to motivate a non-developer. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.

Update (1 year later): after my break from work I ended up at the same company. So the rules where definitely a big plus for me starting again. Especially since no one dared to change anything without a developer in the company.

I'm currently preparing to leave my company and writing extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution, etc. by myself. So nobody else has any idea what and how things work. I am/was also the only developer in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. But how can I properly encourage whoever is working on the project to use Git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, and hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use Git. Of course the documentation would include a chapter on how to use Git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-safe.

But I don't really know how to motivate a non-developer. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.

I'm currently preparing to leave my company and writing extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution, etc. by myself. So nobody else has any idea what and how things work. I am/was also the only developer in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. I have been using Git for my work there for the last three years. How can I properly encourage whoever is working on the project to continue to use Git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, and hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use Git. Of course the documentation would include a chapter on how to use Git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-safe.

But I don't really know how to motivate a non-developer. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.

I'm currently preparing to leave my company and writing an extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution etc. by myself. So nobody else has any idea what and how things work. I am/was also the only dev in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. But how can I properly encourage whoever is working on the project to use git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use git. Of course the docs would include a chapter on how to use git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-save.

But I don't really know how to motivate a non-dev. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.

Note: If someone has some better tags, feel free to add them.

I'm currently preparing to leave my company and writing extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution, etc. by myself. So nobody else has any idea what and how things work. I am/was also the only developer in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. But how can I properly encourage whoever is working on the project to use Git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, and hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use Git. Of course the documentation would include a chapter on how to use Git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-safe.

But I don't really know how to motivate a non-developer. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.