Written by Technical Consultant Stewart Osborne Linux Automation specialist, RedHat Certified Engineer and DevOps Practitioner.
Once the migration planning has begun and the user base for Git has been established, it’s essential that everyone who will be using Git is properly trained to do so BEFORE the migration starts. Git is not particularly complex in its day-to-day usage, especially for those who are familiar with other VC solutions. However, ensuring that all users across the organisation have a base understanding of how Git works will allow for the correct implementation decisions to be made during the migration. It will also allow Developers, Engineers and anyone who contributes to your code-base to “hit the ground running” post-migration.
Exactly how you go about training your staff is entirely up to you. You could send them to an external company that offers Git training. You could hire a trainer to deliver on-site training or you could even have the training delivered by existing staff with a good working knowledge of Git. However you decide to go about it, here are some recommendations from me about what the training should include:
Start with command line usage!
On a day-to-day basis, many Git users will resort to a variety of IDEs to perform most – if not all – of their Git related tasks. IDEs make it easier to navigate complex branching structures and perform rudimentary tasks with the click of a mouse. But these tools are often dangerous in the hands of users who do not understand the basics of how Git works. I have found that introducing users to Git as a CLI helps them to build a better understanding of what is happening behind the scenes and how Git really works. This won’t stop them from using an IDE later on, but hopefully, when they come to do so they will understand the implications of those mouse clicks!
If you have a basis for comparison, use it!
In almost all cases these days, organisations migrating to Git will be migrating away from an existing VC tool. This means that users will already have a good understanding of the principals of version control. Use that knowledge as a starting point when training users to use Git. Reference their existing tool as a basis of comparison, highlighting the key differences between their existing VC tool and Git.
Where possible, show real-life examples of where the tools differ and how to use them accordingly.
Focus on the fundamentals!
Git has a plethora of different functions and features, ranging from the ingeniously helpful and commonly used to the outlandishly odd single use cases. Attempting to train your users to be familiar with all (or even most) of Git’s features is a fantasy. Focus on the bare bones of the tool, how it works and how it is most commonly used. Any engineer who is familiar and comfortable using Git on a day-to-day basis will be perfectly capable of finding solutions to rare use cases using their favourite search engine.
To supplement the training, and to assist users in their work immediately post-migration, I would also recommend having a number of Git “evangelists” available to help with teething issues. Anyone who is experienced and confident in using Git would be able to do this – they simply act as the first point of contact for anyone struggling with the tool after the first few days of migrating. This helps to ensure that productivity is impacted as little as possible during the transition period.
In part three Stewart looks at the Repository Migration – coming soon!