Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Git 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 graph rather than the command list, so merge, rebase, reset, revert, cherry-pick, reflog and bisect become predictable moves on a structure attendees can draw before they type. The syllabus is weighted toward the work that actually costs teams days: interactive rebase to make a long-lived branch reviewable, conflict resolution when several vendors edit the same module, recovering commits after a hard reset or a force-push onto a shared branch, log archaeology with pickaxe search and blame, and automated bisect driven by a real test command. It also covers the two constraints most courses skip entirely — very large repositories carrying binary and calibration assets, handled with LFS, partial and sparse checkout, submodules and subtrees, and migration from Subversion, ClearCase or Perforce with author mapping and branch and tag reconciliation — plus how to prepare work that satisfies a protection policy somebody else wrote. All of it is drawn from twenty years spent building and running systems in DevOps, SRE and security roles, and from over 10,000 engineers taught along the way.
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 — Git branching, history repair and large-repository practice for Pune engineering teams — 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.
Onsite delivery covers Hinjewadi, Talawade, Hadapsar, Kharadi, Baner, Magarpatta and Viman Nagar, and we travel to Pimpri-Chinchwad for engineering IT teams; you provide the room, a screen and network, we bring trainer, agenda, lab repositories, assessments and certificates. Hours are 09:30 to 17:30 IST, and this is one batch that works well as three or four short 08:00 to 13:00 IST sittings rather than consecutive full days, because the recovery and rebase material needs practice between sessions. The highest-value preparation is a sanitised clone of one of your own repositories — we run the history, bisect and conflict labs against your real branching mess rather than a synthetic one, under NDA if required, and if the repository is large we cover the LFS and partial-clone options before the session so nobody spends an hour cloning. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 content-addressed object store with a version control interface on top of it. A commit is a snapshot of an entire tree, identified by a hash over its content and its parents; branches are movable pointers into the resulting graph; and every clone carries the whole graph rather than a thin checkout that depends on a server. That last property is the one that matters most to the teams who book this batch. It means history is portable, recoverable and rewritable — and it also means a repository that has been carrying binary assets for five years is heavy for every person and every build agent that clones it.
Most Pune engineering groups do not meet Git as a first version control system. They meet it as the destination of a migration off Subversion, ClearCase or Perforce, carrying a decade of history, branch names that do not map cleanly onto anything, and calibration data, model artefacts, vendor SDKs and generated code sitting in the same tree as source. That combination changes which parts of Git are worth knowing well: Git LFS and the judgement about which assets belong in an artifact repository instead, partial and sparse checkout, submodules against subtrees, and history conversion that preserves authorship and tags without importing every mistake alongside them.
The second local reality is that the engineer frequently does not own the host. Branch protection, required reviewers, merge strategy and tag policy are set by a customer, so the skills that pay are the ones that work inside somebody else's rules: rebase discipline on a long-lived branch, conflict resolution when two vendors edit the same module, reflog and ORIG_HEAD recovery after a shared branch has been force-pushed, and bisect to isolate which of last week's forty merges broke a nightly build. Git commands are easy to learn. Git history under those constraints is the actual job.
The Git work being bought in Pune is remedial, and that is not a criticism of anybody. Engineering IT groups around Pimpri-Chinchwad and the older Hinjewadi accounts are finally moving history that has sat in Subversion or ClearCase for a decade, and the conversion turns out to be the easy part. What follows is a team whose instincts were formed by a centralised, lock-based tool now working in a system where two people can deliberately edit the same file at the same time.
At the same time repository shape has become an operational problem in its own right. ER&D programmes carry binary and calibration data in the tree, a clone takes the better part of an hour over a shared line, and that cost lands again on every new joiner and every build agent. LFS, sparse checkout and a hard decision about what should never have been committed are worth more to those teams than any quantity of workflow theory.
The third driver is that delivery is now triggered by Git events. Branch names, tag patterns and merge results start builds, releases and deployments, so a team that cannot state its branching strategy cannot design its pipeline either — and when the host and its protection rules belong to a customer, that strategy has to be negotiated rather than declared. Local listings rarely name Git on its own; they assume fluency alongside an automation server and a review tool, and a batch gets booked at the point where the assumption stops holding.
This batch starts where the teams booking it already are: inside somebody else's repository, with history that has to be understood before it can be changed. Blobs, trees, commits and tags as content-addressed objects, refs and HEAD as pointers into the graph, the three trees, and how to read an unfamiliar history — merge topology, ancestry, and what the shape of the graph tells you about how that team actually works.
Topics: Objects: blobs, trees, commits and annotated tags · Content addressing, and exactly what a commit hash covers · Refs, HEAD, branches and tags as pointers into the graph · The working tree, the index and the object store · Ancestry references and commit range syntax · Reading a merge topology from the log graph · Config scopes: system, global, local and worktree · Line endings, autocrlf and the cross-platform trap
Everything later in this syllabus — review, bisect, cherry-pick, revert — depends on commits that each mean one thing. Partial staging, splitting and combining work in progress, amending and when amending is unsafe, reading staged against unstaged differences, and handling renames, moves and deletions the way Git genuinely records them. Then commit messages written for the person who runs blame on that line two years from now.
Topics: The index as the place you compose the next commit · Partial and interactive staging with add -p · Amending, and the point at which amending stops being safe · diff, diff --staged, and diffing arbitrary points in history · Deleting, moving and renaming, and how history follows content rather than names · Stash for parking work, including untracked files · Commit messages that survive being read a year later · gitignore matching, global ignores, and why ignoring a tracked file does nothing
Branches are pointers and merges are graph operations, and almost every confusing outcome follows directly from that. Creating, switching, comparing, renaming and deleting branches, switching with uncommitted changes, fast-forward against true three-way merge and the merge base that decides which one happens, what a merge commit records, and the structural changes that make future integrations cheaper.
Topics: Branches as pointers: creating, renaming and deleting, including unmerged branches · Switching with uncommitted changes, and switch versus checkout · Detached HEAD: what it is, and leaving it without losing commits · Fast-forward versus true merge, and the merge base · What a merge commit records, and how to read one later · Merge strategies and options: ours, theirs, and the default strategy · Aborting a merge cleanly · Structuring code and branches so future conflicts are smaller
Conflict resolution as a repeatable method rather than an improvisation under deadline. Reading conflict markers and the stages the index holds during a conflict, choosing a resolution approach per file type, merge tools and diff3 style, rerere for conflicts you know you will hit again, and the specific case services teams live with — two vendors changing the same module against a protected branch where neither side can simply overwrite the other.
Topics: Why a conflict happens, and what the index holds while one is open · Reading conflict markers, and bringing in the common ancestor with diff3 · Resolving with a merge tool, and resolving by hand · Conflicts in generated files, binary assets and configuration · rerere: recording a resolution and having it replayed · Conflicts during a rebase versus conflicts during a merge · Long-lived branches, and integrating early to keep conflicts small · Agreeing a resolution protocol between two teams that share a module
The tools that decide what a reviewer sees. Rebase as replay and what it does to commit identity, interactive rebase to squash, fixup, reword, reorder, split and drop, autosquash from fixup commits made during review, cherry-pick for moving individual commits between branches, and the rule about shared branches stated precisely enough that you know when it can be broken safely.
Topics: Rebase as replay: new commits, new hashes, the same content · Rebase versus merge, and the rule for shared branches stated exactly · Interactive rebase: squash, fixup, reword, edit, reorder, drop · Splitting a commit during an interactive rebase · Autosquash and fixup commits during a review cycle · Cherry-pick, including cherry-picking a merge commit · rebase --onto, and moving a branch off the wrong base · Conflicts mid-rebase: abort, skip and continue, and choosing between them
The module that pays for the batch. Every routine way work disappears, and the specific recovery for each: a hard reset, a bad amend, a deleted branch, an abandoned rebase, a detached HEAD, and a force-push that overwrote a colleague's commits on a shared branch. Reflog, ORIG_HEAD, dangling objects and fsck, plus the operational habits that make recovery possible in the first place.
Topics: Soft, mixed and hard reset demonstrated against the three trees · revert versus reset, and which one is legal on a shared branch · reflog: per-repository, per-branch, and its expiry window · ORIG_HEAD and recovering from an aborted operation · Recovering a deleted branch and a commit with no ref pointing at it · fsck, dangling objects and the garbage collection window · Rebuilding a shared branch after somebody force-pushed over it · force-with-lease as the habit that prevents most of this · Removing a committed credential or a large file from history, and its consequences
Investigating a regression using history rather than a debugger. Log filtering and formatting, searching content history with the pickaxe, blame with copy and move detection so a refactor does not hide the author, and bisect: manual first, then automated against a test command, including how to skip commits that will not build. This is the fastest route through last week's forty merges to the one that broke the nightly run.
Topics: Log filtering by path, author, date, range and merge status · Searching content history with log -S and log -G · blame with whitespace, copy and move detection · show, diffing between tags, and answering 'what changed in this release' · bisect start, good, bad and reset · bisect run against an automated test command · bisect skip and genuinely untestable commits · Investigating a regression across a merge-heavy history
Where Git stops being personal and starts being contractual. Remotes and refspecs, tracking branches, fetch against pull, rejected pushes and the three ways to resolve one, pruning stale references — and then the constraint most services teams work under: branch protection, required reviewers, required status checks, a merge or squash or rebase policy, and a tag policy set by a customer you cannot ask to change it.
Topics: Remotes, refspecs and tracking branches · fetch versus pull, and pull with rebase · Rejected pushes, and the three ways to resolve one · force-with-lease, and the rare case where force is defensible · Pruning stale remote-tracking references · Branch protection, required reviewers and required status checks · Merge commit, squash merge and rebase merge policies compared · Multiple remotes and a customer-hosted upstream · Preparing a change so it passes a policy you did not write
What to do when the repository carries calibration data, model artefacts, vendor SDKs or generated code alongside source. Git LFS — tracking rules, pointers, migrating existing history and the storage behind it — then partial clone and sparse checkout for working on one part of a large tree, shallow clones for build agents and their limits, and submodules against subtrees for vendored code.
Topics: Why large binaries hurt: clone time, pack size, and every future developer · Git LFS: tracking rules, pointer files, and migrating existing history · Hosting LFS content and the storage that sits behind it · Partial clone with filters, and sparse checkout · Shallow clones for build agents, and where they break · Submodules: pinning, updating, and the characteristic failure modes · Subtrees as the alternative, and the trade-off between them · Deciding what belongs in version control and what belongs in an artifact repository · Repacking, maintenance and measuring repository health
Moving a decade of history without importing every mistake in it. Assessing the legacy repository, deciding what to convert and what to archive, author mapping, reconciling branches and tags where the source model does not map cleanly, moving binaries into LFS during the conversion rather than afterwards, verifying the result against the source of record, and running a parallel period so the old system can be retired instead of abandoned.
Topics: Assessing a legacy repository: size, branches, tags, binaries, dead history · Deciding what to convert, what to archive and what to drop entirely · Author mapping and identity reconciliation · Converting Subversion history across trunk, branches and tags layouts · ClearCase and Perforce conversion approaches and their limits · Moving large binaries into LFS during conversion rather than after it · Verifying a conversion against the source of record · Parallel running, freeze windows and cut-over sequencing · Retraining a team whose instincts come from a lock-based tool
The agreements that make everything above repeatable. Lightweight against annotated against signed tags, tag conventions a pipeline can trigger on, retagging when a release was cut from the wrong commit, client and server-side hooks and the difference in what each can enforce, and the workflow comparison done honestly against release cadence, review load and a protection policy that may not be yours to set.
Topics: Lightweight, annotated and signed tags · Signing commits and verifying provenance · Tag conventions that a release pipeline can consume unambiguously · Retagging safely when a release was cut from the wrong commit · Client-side hooks, and why they are advisory only · Server-side hooks and policy enforced where it cannot be bypassed · Centralised, feature branch, GitFlow, forking and trunk-based workflows compared · Choosing a strategy when the host and its rules belong to a customer · GUI clients and IDE integration, including SourceTree, and where they mislead
We rebuild the agenda around the tools you actually run.
Request a custom agendaGiven an unfamiliar history, reconstruct its branching model, find where its conventions break down, and predict the outcome of three commands before running any of them.
Reshape a branch full of work-in-progress commits, a typo fix and a reverted experiment into reviewable history using interactive rebase and autosquash.
A shared branch is overwritten. Recover the lost commits with reflog and fsck, rebuild the branch, then put force-with-lease in place so it cannot happen the same way again.
Automate a bisect against a real test command across a merge-heavy history, skip the commits that will not build, and produce the offending change with evidence.
Migrate binary and calibration assets into LFS, set up a sparse checkout for one component, and measure clone time and pack size before and after the change.
Convert a legacy repository with author mapping and branch and tag reconciliation, move its binaries into LFS, verify the result against the source, and write the cut-over plan.
Git training gets bought in Pune for two very specific reasons, and almost never for "what is a commit". The first is migration debt. Engineering and manufacturing IT across Pimpri-Chinchwad, Chakan and the older Hinjewadi accounts still holds a decade or more of history in Subversion, ClearCase or Perforce, and the projects that finally move it want history preserved, binary assets handled sanely and a branching model that will survive an audit trail question. The second is repository shape: Pune's ER&D programmes carry calibration data, model artefacts, generated code and vendor SDKs in the same tree as source, so the practical curriculum is Git LFS, sparse and partial checkout, submodules versus subtrees, and why a very large clone crawls over a shared office line.
The engineering-services floors in Hinjewadi, Talawade and Hadapsar add a constraint that is easy to miss from outside the city: the engineer usually does not own the Git host. Branch protection, required reviewers, merge strategy and tag policy are set by the customer, so the skills that pay are working cleanly inside somebody else's policy — rebase discipline on a long-lived feature branch, conflict resolution when two vendors touch the same module, reflog and recovery after a shared branch is force-pushed, and bisect to find which of last week's forty merges broke a nightly build. Local listings rarely advertise Git on its own; they list it beside an automation server and a review tool and assume fluency, which is precisely why teams book a batch only once the assumption fails.
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| 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 advisorPrefer to call or email?
More ways to reach us on the contact page.