Private corporate batches, live online cohorts and 1-on-1 mentoring in distributed version control — branching, merging, rebasing and collaboration workflows that hold up under pressure — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Git from the object model outward — the three-tree architecture, content-addressed commits, HEAD and branch pointers — so that merge, rebase, reset, revert, cherry-pick and reflog become predictable moves on a graph rather than memorised commands. Sessions cover the parts teams actually get wrong: conflict resolution strategy, rebasing shared branches, recovering work that looks lost, .gitignore against already-tracked files, and choosing between GitFlow, feature-branch, forking and trunk-based workflows for a specific release cadence. Everything is demonstrated live in real repositories, including deliberately broken ones.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Git that means a trainer who has run it in production — distributed version control — branching, merging, rebasing and collaboration workflows that hold up under pressure — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Git batchGit is a distributed version control system created by Linus Torvalds in 2005 to manage Linux kernel development. Distributed means every clone is a complete repository — full history, all branches, all tags — not a thin checkout that depends on a server. Committing, branching, diffing and searching history are local operations, which is why Git is fast and why it keeps working when the network does not.
Under the surface Git is a content-addressed object store. A commit is a snapshot of the whole tree, identified by a hash of its content and its parents, so history is a directed graph of immutable objects rather than a sequence of file deltas. Three trees govern day-to-day work: the working directory you edit, the staging area — the index — where you compose the next commit, and the repository where commits land. Branches are nothing more than movable pointers into that graph, and HEAD is a pointer to the branch you are on. Once that model is clear, the commands stop being incantations: merge, rebase, reset, revert, cherry-pick and reflog are all just moves on the same graph.
In practice, teams do not struggle with Git commands; they struggle with Git history. Which branch merges where, when to rebase and when never to, what reset --hard actually destroyed, how to recover a commit that appears to have vanished, and how to keep a shared branch usable when twenty engineers push to it. That is the difference between using Git and operating it.
Git is not a competitive choice any more, it is the substrate. Every mainstream hosting platform, CI system, code review tool, GitOps controller and package registry assumes a Git repository underneath, and increasingly assumes a specific shape of history: signed commits, linear or merge-committed main, protected branches, tags that map to releases.
That raises the bar. A decade ago, knowing clone, commit and push was enough. Now the delivery pipeline itself is driven by branch names, tag patterns and merge events, so a team that cannot articulate its branching strategy cannot design its pipeline either. Trunk-based development, release branches, GitFlow and forking workflows each imply a different CI topology, different protection rules and different release mechanics.
The second driver is recovery. Distributed history means mistakes are almost always reversible — but only for people who understand reflog, reset modes, revert on a shared branch, and how to rescue work from a detached HEAD. Teams lose real days to problems that take a competent Git operator two minutes, and that gap is what training closes.
What version control is for, how distributed differs from centralised, and why that difference changes daily work rather than just the server topology. Then a correctly configured Git on every machine in the room — installation across macOS, Windows and Linux, identity and editor configuration, auto-completion and the built-in help system.
Topics: What is Git and what version control solves · The history of Git and why it was built · Distributed versus centralised version control · Installing Git on macOS, Windows and Linux · Configuring Git: identity, editor, line endings, config scopes · Git auto-completion and using git help
The mental model everything else depends on. Initialising a repository and looking at what is actually inside .git, making the first commits, and then the architecture: working directory, staging area and repository, the SHA-1 object names, and the HEAD pointer that tells Git where you are.
Topics: Initialising a repository · Where Git stores its files — inside .git · Performing your first commit · Writing commit messages that stay useful · Viewing the commit log · The three-tree architecture and the Git workflow · Hash values (SHA-1) and content addressing · Working with the HEAD pointer
The daily loop, done precisely. Adding and editing files, reading diffs of unstaged and staged changes separately, and handling deletes, moves and renames the way Git actually records them — as content, not as tracked rename operations.
Topics: Adding and editing files · Viewing changes with git diff · Viewing only staged changes · Deleting files with git rm · Moving and renaming files · Partial staging with git add -p
The module that pays for the course. Every level of undo — discarding working directory changes, unstaging, amending, retrieving old versions, reverting a published commit, and the three reset modes — with a clear rule for which is safe on a shared branch and which is not. Then recovery: reflog, and getting back commits that appear to be gone.
Topics: Undoing working directory changes · Unstaging files · Amending commits · Retrieving old versions of a file · Reverting a commit · Using reset to undo commits · Soft, mixed and hard reset demonstrated · Removing untracked files with git clean · Recovering lost commits with reflog
Repositories rot when the wrong things are committed — build output, IDE settings, dependency directories, credentials. How .gitignore matching actually works, the difference between global and per-repository ignores, why ignoring an already-tracked file does nothing, and how to track a directory that must exist but must stay empty.
Topics: Using .gitignore files and pattern matching · Deciding what to ignore · Ignoring files globally · Ignoring files that are already tracked · Tracking empty directories · Removing committed secrets and large files from history
Reading history like a practitioner. Every way to reference a commit — hashes, HEAD, ancestry with ~ and ^, branch and tag names — plus tree listings, high-signal log formatting, and comparing any two points in history.
Topics: Referencing commits: hashes, HEAD, ~ and ^ · Exploring tree listings with git ls-tree · Getting more from the commit log — formatting, filtering, graph view · Viewing commits with git show · Comparing commits and branches · Searching history with log -S and git blame
Why branches in Git are cheap, and what that changes. Creating, listing, switching, comparing, renaming and deleting branches, and the specific case that confuses everyone — switching branches with uncommitted changes in the working directory.
Topics: Branching overview — branches as pointers · Viewing and creating branches · Switching branches, and creating and switching in one step · Switching branches with uncommitted changes · Comparing branches · Renaming branches · Deleting branches, including unmerged ones · Detached HEAD: what it is and how to leave it safely
Merging as a graph operation. Fast-forward versus true three-way merges and when each occurs, what a merge commit records, and conflict resolution as a workflow rather than a panic — reading conflict markers, choosing a strategy, and the structural changes that make conflicts rarer in the first place.
Topics: Merging code into a branch · Fast-forward merge versus true merge · Three-way merge and the merge base · How merge conflicts arise · Resolving merge conflicts, including with a merge tool · Aborting a merge safely · Strategies to reduce merge conflicts
The tools that shape history before anyone reviews it — and the rule about when not to use them. Rebase versus merge and what actually happens to commit identity, interactive rebase to squash, reorder, edit and fix up, cherry-pick for moving individual commits, and the stash for parking work mid-task.
Topics: Rebasing: replaying commits onto a new base · Rebase versus merge, and the golden rule for shared branches · Interactive rebase — squash, fixup, reword, reorder, drop · Cherry-picking commits between branches · Saving changes in the stash · Viewing, retrieving and deleting stashed changes · Resolving conflicts during a rebase
Where Git stops being personal. Local versus remote repositories, adding and inspecting remotes, cloning, tracking branches, and the fetch-then-merge model that pull hides. Then the collaboration mechanics: pushing to an updated remote branch, deleting remote branches, and the safe alternative to force push.
Topics: Local and remote repositories · Adding a remote repository · Cloning a remote repository · Creating a remote branch and tracking branches · Pushing changes to a remote · Fetching changes and merging fetched changes · Checking out remote branches · Pushing to an updated remote branch and rejected pushes · Force-with-lease instead of force push · Deleting a remote branch and pruning stale references · A collaboration workflow end to end
Marking points in history that other systems depend on. Lightweight versus annotated tags and why only one of them carries a message and an author, signed tags for provenance, pushing and checking out tags, and mapping a tag convention to a release process that CI can trigger on.
Topics: Lightweight tags · Annotated tags · Signed tags and commit signing · Creating tags from the command line and from a hosting UI · Viewing and checking out tags · Pushing and deleting tags on a remote · Tag conventions that drive release pipelines
How real teams organise. Centralised, feature-branch, GitFlow, forking and trunk-based workflows compared on release cadence, review load and CI cost — with an honest statement of where each fails. Then the surrounding tooling: aliases, SSH keys, hooks, IDE and GUI clients including SourceTree, and a structured approach to troubleshooting.
Topics: Branching basics and forking basics · Centralised workflow · Feature branch workflow · GitFlow workflow · Forking workflow · Trunk-based development and short-lived branches · Setting up aliases for common commands · Using SSH keys for remote access · Client-side hooks and their limits · IDE integrations and GUI clients · SourceTree: local repositories, tags, .gitignore, removing files · SourceTree: cloning and working with remote repositories · Understanding Git hosting options · Git troubleshooting: diverged branches, large files, corrupt index
We rebuild the agenda around the tools you actually run.
Request a custom agendaWork through staging, committing and inspecting objects while predicting the effect on each of the three trees before running anything — the fastest route to an accurate mental model.
Lose work five different ways — hard reset, deleted branch, bad amend, botched rebase, detached HEAD — and recover from each using reflog and ORIG_HEAD.
Two engineers restructure the same files on parallel branches. Merge them, resolve the conflicts deliberately, then redo the same integration as a rebase and compare the resulting history.
Take a nine-commit branch full of WIP, typos and a reverted experiment, and reshape it with interactive rebase into three commits a reviewer can actually read.
Run a complete collaboration cycle across three working copies — branch, push, review, integrate, tag and clean up remote branches — including a rejected push and a force-with-lease.
Choose a workflow for a stated release cadence and team size, implement it in a repository with protection rules and tag conventions, and demonstrate a hotfix travelling through it.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
Good discussion, helped us to understand different tools in SRE.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.