Git Training: Version Control That Holds Up in a Team
Almost every team uses Git. Far fewer use it confidently. Two days that close the gap: a solid model of what Git actually does – and workflows that still work when things get tight.
- Level
- Beginner – Intermediate
- Duration
- 2 days
- Formats
- On-site · Remote
Focus areas
- Team branching strategies
- Rebase, merge & a clean history
- Code review & pull requests
- Conflicts, recovery & bisect
Who this training is for
Development teams who use Git daily and still hit the same walls: a merge nobody wants to resolve; a history in which it is no longer traceable why a line looks the way it does; a branching model adopted from a blog post that never quite fitted the team’s release rhythm.
Equally for mixed teams where some colleagues move confidently while others rely on three memorized commands – a gap that gets expensive in code reviews and during conflicts.
Contents
Day 1 – The model and daily work. What Git actually stores: objects, references, the index. That model is the source of most confusion – once it sits properly in your head, unfamiliar commands start making sense too. Building on it: branching strategies compared (trunk-based, release branches, feature branches), what each assumes and what each costs. We place your current model in that picture and work out where it chafes.
Day 2 – History, review and emergencies. Rebase versus merge, and when each is the better answer. Interactive rebase for tidying up before review. Commits that make sense as a unit, and messages that still explain something a year later. Code review as a workflow rather than a formality, and how it connects to CI. Finally the recovery drills: retrieving lost commits through the reflog, using bisect to pin down an introduced bug, resolving conflicts in large merges systematically.
What your team can do afterwards
Choose a branching strategy deliberately and justify it, rather than inheriting one. Prepare a change so that review is both fast and thorough. Narrow a bug down to a single commit with bisect in minutes. And – the underrated part – stay calm in a tangled situation, because it is clear that almost nothing in Git is ever truly lost.
Prerequisites
Practical day-to-day experience with Git: committing, pushing, working in branches. No knowledge of the internal structure is assumed – we build that together.
Format and delivery
Two days, on site or remote. Exercises run in repositories we deliberately steer into the situations under discussion – conflicts and tangled histories are hard to talk about without one in front of you.
On request we spend part of day two on your own repository and your actual workflow. That is the part teams typically take the most from – but it requires that you want to give us that visibility. Without it we work with realistically reconstructed examples.
Frequently asked questions
- Our team has used Git for years. Is this still worth it?
- Especially then. Most teams master one well-worn path and never step off it – until a merge goes wrong or a history becomes useless. With experienced teams we focus on branching strategy, review workflows and the situations that cause anxiety: interactive rebase, lost commits, `bisect`.
- Which platform is used – GitHub, GitLab, something else?
- The concepts are platform-independent and we align the exercises with your setup. GitHub, GitLab, Forgejo/Gitea or another interface: we work with what your team actually uses so the workflows transfer directly.
- What does a "clean history" mean in practice – isn't that a matter of taste?
- Partly, which is why we teach consequences rather than doctrine. A history is good when it answers the questions you will later ask it: when did this bug appear, what belonged to this change, what can be reverted safely. Which conventions get you there is your team's decision – we show the options and their price.
- Is this purely about Git or also about the development process?
- Both, because one is of little use without the other. Branching strategy, review culture and CI integration are connected: a strategy that does not match your release rhythm gets worked around, however good it looks on paper.
Articles on this topic
Going deeper, from our blog – the same topics at length.
Hardware-in-the-Loop Testing: CI/CD With Real Embedded Hardware
Why hardware-in-the-loop testing is the missing piece for real CI/CD on embedded devices — catching driver, timing and integration bugs on the target.
- Testing
- CI/CD
- Hardware-in-the-Loop
Other trainings
Modern C++
From move semantics and smart pointers to the additions in C++20/23: write safe, expressive and performant modern C++ code.
3 daysQt & QML in Practice
A hands-on introduction to the Qt world: building applications with Qt Quick and QML, connecting C++ logic and designing performant user interfaces.
2 daysEmbedded Linux Fundamentals
Understand the anatomy of an Embedded Linux system – from bootloader and kernel to the root filesystem and your own application on real hardware.
3 daysYocto Project Intensive
Build your own Linux distribution with the Yocto Project: BitBake, custom layers and recipes, image customization and reproducible builds in CI.
This training for your team?
Tell us how many participants, where they stand and your timeframe – we'll come back with a proposal and dates.
Start a project