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.

  • Apart from forcing them to do so, what makes you concerned that the steps you have mentioned won't be enough? Also, if you're the sole developer writing up this process, why can't you make it part of the standard process?
    – user34587
    Sep 10, 2018 at 8:36
  • Currently the chapter on git isn't written yet, so I'm currently looking for what to write there to give a practical motivation. Making git part of the standard workflow was also my idea but as it does not contribute to a successful installer it might get skipped - thats what I want to motivate against. But maybe I'm overthinking this, that is also a possibility.
    – CShark
    Sep 10, 2018 at 8:38
  • 3
    Related, possible duplicate: Convince the Company I Work for to Implement Version Control?
    – David K
    Sep 10, 2018 at 13:21
  • 5
    Why git in particular, rather than one of the dozens of other version control systems?
    – jamesqf
    Sep 11, 2018 at 5:21
  • 3
    @jamesqf Because it is what I chose to use the last three years. My successor is of course free to change everything, but until then it is easier to just continue using it.
    – CShark
    Sep 11, 2018 at 8:37

4 Answers 4


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.
  • 80
    +1 Even better if there's a CI / build pipeline system in place. Then that becomes the path of least resistance, and you can trust human laziness to take over :)
    – rath
    Sep 10, 2018 at 10:42
  • 7
    Uh, It never occured to me that I could just use a buildbot which directly works on the git repo to force the use of git... I think I will go with that and make it part of the workflow :)
    – CShark
    Sep 10, 2018 at 10:59
  • 9
    @rath I can personally confirm that this doesn't always work. I was in the same situation a while ago, and when they took over the software they immediately ignored the clearly documented build process and just did production modifications (it was php, so they'd just edit files in the web root). Sadly, you can only do so much before you just need to wash your hands and walk on. If the person who replaces you is smart enough, they will use it. If they aren't, they won't.
    – Shadow
    Sep 11, 2018 at 6:48
  • 4
    @Shadow You can lead a horse to water...
    – rath
    Sep 11, 2018 at 8:53
  • 2
    @CShark never underestimate how much work people will go though to avoid learning a new technology!
    – corsiKa
    Sep 11, 2018 at 15:08

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)


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.

  • 11
    Did I miss anything? I though MS bought GitHub - not necessarily Git?
    – dokgu
    Sep 11, 2018 at 14:18
  • 2
    this reads more like a rant, see How to Answer
    – gnat
    Sep 12, 2018 at 10:13
  • I don't use Git and it's 2019. :P
    – Cypher
    Aug 13, 2019 at 20:08

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.

  • 7
    This is more commentary than a real answer. Please see How to Answer and take our tour to improve your answer.
    – Burgi
    Sep 10, 2018 at 15:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .