How I got our developer team to switch from vcs to subversion then to git (gitlab)

I am working in this company for about 10 years now and when I started we used Visual Source Safe (anyone still remembers?) oh it was awful, it was set to lock your source code so nobody could change that file when it was locked for you. That alone it was a pain, the plus side it there was no conflict to resolve, but slowed the development considerable.

After about 3 years working like a living nightmare I discovered about subversion and I thought “well that is a nice manner to control your versions, with trunk, tags and branches” little that I know that the other developers would not work within the guidelines and would put all projects inside a giant project, would not use tags and branches as intended and would change files direct in the trunk :( .

We could not control the versions that we shipped, we had like 10 branches for project with different versions, and we maintained every branch, so if we would change something from a branch we had to pass the changes to every single branch, it was highly error prone.

About 3 years ago I asked myself: What are we doing? the objective to get a version control software it is to control the version and we aren't doing even this. So I was already using Git Hub for my personal projects, and I liked to work with him better than Subversion, so I searched for a Git version control that:

1- Would run on premises.
2- Was free.

Then I came across of GitLab (www.gitlab.com) their version of a free git server that runs on premises is simple fantastic, it is open source and the community loves to implement and fix bugs periodically.

First thing I should implement was some guidelines and force on the developers:

1- Using groups for grouping projects.
2- Only one source code for project on GitLab. (Remember that they used to have various source codes for various softwares inside only one project in Subversion?)
3- Branch: master is protected and is the branch for implementations to be merged.
4- Branch: maintenance is protected and is the branch for fixed bugs to be merged and cherry picked to master.
5- Only one merge (pull-request for github users) for Issue.
6- Create branches from issues.
7- Creating milestone to further control the versions.
8- When a version is released every issue and merged (pull-request for github users) from that milestone should already be closed, and then it is created a tag for that version.
9- A merge (pull-request for github users) is only accepted if the feature was tested.
10- The version for test is generated using GitLab CI and is on the merge page for download. (Before a person would generate the binaries by hand)

Now we only support the last version that was released from the branch maintenance instead of 10 different versions.

Feel free to leave some input about how I should keep improving how we control our version of the software.

Thanks.