Git should be practised as a collaboration system
Running git add, commit and push on your own shows the syntax, but does not teach you how to work with a history created by several people. Most questions come up around diverging branches, conflicts, amending an earlier commit and choosing how to integrate changes. These situations have to be designed into the training scenario.
The lab can consist of a separate machine for each participant and a shared remote repository prepared solely for the sessions. The code does not have to come from the company's product. A small project with tests and a few interdependent files is enough to make the consequences of changes visible.
Identity and authentication are part of the configuration
Each account should have its own user name and the e-mail address used in commits. That way, the history shows who made a change, and the instructor can discuss the meaning of author and committer. It is not a good idea to use one shared SSH key or token for the whole group, because it blurs accountability and makes it harder to revoke access.
Credentials should only work for the duration of the training. If the exercises include signing commits, branch protection or pull requests, you need a service that actually supports those mechanisms. A simpler remote Git server is enough for learning the basics. The choice of tool should follow from the programme, not from habit with a particular platform.
A good conflict is no accident
A conflict prepared for an exercise should have a clear cause and several sensible resolutions. Two people can change the same piece of configuration with different intentions and then agree on the final version together. The instructor assesses not only whether the file is correct, but also whether the participants understand the difference between the branches' contents and how they justify their decision.
An accidental conflict in a large auto-generated file mainly teaches caution, but says little about the Git model. In training, it is better to use a short piece of code, a test or a document in which the participant can compare both sides and build the result deliberately.
A mistake should leave a trail to analyse
A dedicated repository lets you safely practise reset, revert, rebase and recovering a commit through reflog. Before running a command, the participant should predict what will happen to the index, the working directory and the history. After the operation, they compare the prediction with the result.
The point is not to memorise a list of “dangerous” commands. It is more important to distinguish local changes from published ones, and an operation that rewrites history from a commit that reverts an earlier change. The lab can be restored, but it is worth reading the graph first and working out why the repository ended up in that state.
The scenario should have checkpoints
After each stage, you can check an observable state: the name of the current branch, its relationship to the remote repository, the test results and the commit graph. An automated script can confirm whether the expected commit exists and whether the files contain the correct result. It should not assess the style of collaboration based solely on the final tree.
The instructor also needs a way to tell whether a problem concerns Git, repository permissions, the network or the project itself. A common client version, the same configuration and an identical starting point shorten diagnosis considerably. The instructor panel, or access to a selected workstation, helps when the participant agrees to receive support.
A reset must not destroy the whole group's work
Each participant should have their own fork, repository or set of branches that can be recreated without interfering with other people's exercises. Shared team tasks require separate groups and copies of the base repository. A reset script should delete only the resources belonging to the specified exercise.
Before the next run of the training, it is worth recreating the whole sequence from clean accounts. Leftover branches, tags and protection rules can change how the instructions behave. A configuration left by the previous group is not the baseline, even if the project looks the same at first glance.
After the workshop, keep the history that has teaching value
A participant can be given a copy of the repository with their own commits, provided it contains no company information or other people's data. Sample solutions, history graphs and a short description of the decisions made during the conflict are also useful. Temporary tokens and lab accounts should be disabled.
Separate VMs created from a single base configuration let you prepare an identical Git client, history visualisation tools and a starter project. As a result, the training focuses on the model of working with history, not on differences between local installations.