How do I motivate usage of Git for the next maintainer?

Question

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.

Answer 1

In a situation like yours, a good starting point is to present the current use of Git as the rule.

Add simple instructions like

• Where do I get the current code? Check out the Git repository XYZ.
• How do I make modifications to the code? Use development environment ABC, modify code and commit changes to Git repository XYZ

Include Git into the written rules and guidelines and present it as a natural and ingrained tool in the development process. Adding a list of advantages of Git and worst case scenarios if it isn't used may help to create the illusion that you simply cannot work on this project without using Git.

That has the following effects:

• An inexperienced developer or general IT person without knowledge about software development will take those rules as written and adhere to them (provided that they find and read the rules).
• A new employee will probably take over the existing development process at first and introduce changes gradually if they see any problems with the process.
• An experienced developer knows about the importance of version control and will either keep working with Git or replace it with another solution.

Answer 2

There are two sides to the Git coin. You should cover both.

The first is that it is a DVCS, which means that you (the dev) no longer need permissions to record anything into your repository - control has been distributed to the dev. It is easy and fast to essentially keep notes and to be able to return to any point in your/their rolling development (especially with the fast and easy branch capability). I presume you use some form of triangular flow to distinguish current dev work from approved production / secured work. Having the rolling record will save a lot of grief.

Git also separates out the authorisation and verification aspects to a distinctly separate management role for the acceptance of the work into (typically) the master branch (whether merge or fast forwarded). Historically, on centralised tools, the dev was not allowed to completely commit work until it had gone through many hoops making most devs avoid the configuration tool (which was wrong, but understandable). So now you get the best of both worlds.

The second, flip side, is that Git from the command line can be a real pain with lots of inconsistencies between options and special options to remember. This is ok for some, but others will be happier with the git-gui and gitk tools which provide an alternative graphical interface for those who prefer. Be positive about there being a range of Git tooling options to suit all pockets and mind sets. It (Git) is a great tool but beware of other bad CM habits and misunderstandings based on historic tools.

Remember that historic software configuration management (CM) was based on drawing office practice from before the building of the Titanic - the 'master' drawing had to be protected at all costs, without it there was no ship, no product. Now we have perfect replication, but need verification that the copy we have is absolutely the authorised traceable version (e.g. 1d4361b0f344188ab5eec6dcea01f61a3a3a1670 v2.19.0, just now)

Answer 3

Why do you care? What benefit is there to them doing something you want them to do after you leave? Why are you forcing them to use your chosen tools when you are no longer associated with the company?

You say you were the only developer, what if your replacement is more experienced than you and thinks everything you implemented is crap? Why make it more work for him to have to tear up more of your chosen crap?

Although the real answer is: who doesn't use git in 2018? M$ even owns them.

Answer 4

On some days you made changes, which look good first (they compile) but terrible later on. When you notice such mistakes, you can roll out the better-working old code in an instant, or invest work hours into finding and undoing your changes -> while others have to work with software which doesn't work as intended. Both cost money, while a commit is done within a second and costs nothing.

Another advantage of an repository is that you can check it out easily on different computers. This argument is probably small, since other people in your company probably won't have a git client, as non-developers (I am using it for LaTeX in a non-developing sense too.)

That's why I am using repositories even for my private stuff, not to mention that you need one when your successor isn't a single person.

I guess even a non-developing supervisor knows the importance of change logs and a repository is a powerful change log.