Private corporate batches delivered onsite across Bangalore, 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 object database up: blobs, trees, commits and refs inspected directly with plumbing commands, so merge, rebase, reset and cherry-pick stop being incantations and become predictable moves on a graph. Sessions cover the work teams actually get stuck on — recovering from a bad reset or force-push with the reflog, rewriting history to remove a leaked credential and coordinating the fallout, splitting or migrating a repository with history intact, and making a multi-gigabyte repository usable with LFS, partial clone and sparse checkout — all rehearsed on disposable repositories where breaking things is the point.
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 for Bangalore engineering teams — object model, history repair, large-repository tooling and migrations off legacy version control — 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 is at your own office. Git sessions in Bangalore commonly run in Whitefield, along the Outer Ring Road between Bellandur and Marathahalli, at Manyata Tech Park, Bagmane Tech Park or in Electronic City, and we keep one site per day so a mid-programme city crossing does not cost a session. You provide the room, a screen and network access to your Git hosting; we bring the trainer, agenda, exercise repositories and assessment. Because history-repair exercises are destructive by design, attendees work on disposable clones we supply rather than on your live repositories, and any work against your own history happens on a copy under NDA. Sessions are scheduled in IST (UTC+5:30) and shaped around your review overlap with counterpart teams abroad. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and travel within Bangalore is included in the quote.
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 database with a version control interface on top. There are four object types — blobs for file content, trees for directory structure, commits that point at a tree and at parent commits, and tags — and every one is named by a hash of what it contains. Nothing is stored as a diff at the logical level; a commit is a full snapshot, and the compression that makes that affordable happens later, when loose objects are packed into packfiles with delta encoding.
Everything user-facing sits on that base. Branches and tags are refs: files under .git/refs, or entries in packed-refs, containing a hash. HEAD is a ref pointing at a branch. The index — the staging area — is a binary file holding the tree you are composing for the next commit. Merge, rebase, reset, revert, cherry-pick and stash are all operations that create objects and move refs, which is why the reflog can recover almost anything: the objects usually still exist, only the ref moved, and garbage collection has not yet run.
Distribution is a separate mechanism again. A remote is a URL plus refspecs; fetch negotiates which objects the other side lacks and transfers a packfile; push does the same in reverse and is refused when it would not fast-forward. Once that is clear, the operational features fall into place — shallow and partial clone, sparse checkout and worktrees for repositories too large to check out whole, Git LFS for binaries that should never enter a packfile, submodules and subtrees for composition, and hooks for enforcing policy locally or on the server.
Git stopped being a skill anyone lists and became infrastructure everyone depends on, which is exactly why the gaps hurt. Teams do not lose days to not knowing how to commit; they lose days to a force-push that overwrote a shared branch, a rebase that duplicated forty commits, a merge conflict resolved by deleting the confusing half, or a repository that takes eleven minutes to clone because someone committed a build output tree in 2019.
The stakes rose in two specific ways. Credentials in history became a security incident with a defined remediation — rewrite, rotate, force-update every fork — rather than an embarrassment, and doing that rewrite correctly on a live repository requires knowing exactly what it does to everyone else's clone. And review became the delivery bottleneck in most organisations, so branching model, review latency and merge strategy now show up directly in delivery metrics.
Repository scale is the third pressure. Monorepos, machine learning artifacts, media, firmware images and simulation data have pushed many repositories past the size where a naive clone is reasonable, and the tooling that answers it — partial clone, sparse checkout, LFS, maintenance and commit-graph — is not something people pick up by osmosis. The demand is for engineers who understand the model well enough to repair, restructure and scale a repository, not just to use one.
Git from underneath, using plumbing commands so nothing is magic. Blobs, trees, commits and tags; hashing and content addressing; loose objects, packfiles and delta compression; refs, HEAD, packed-refs and the index as a real file on disk.
Topics: hash-object, cat-file and building a commit by hand · Blobs, trees, commits and annotated tags · Refs, HEAD, symbolic refs and packed-refs · The index as a binary file, and what staging really does · Loose objects, packfiles, delta encoding and gc · Reading .git and knowing what each file does
Every history-shaping command as a predictable operation. Fast-forward and three-way merges, merge bases, rebase and interactive rebase, cherry-pick, squash, and the difference between changing history and adding to it.
Topics: Merge bases and three-way merge mechanics · Fast-forward, no-ff and what the history looks like afterwards · rebase, rebase --onto and interactive rebase · cherry-pick, revert and the difference from reset · Squash strategies and what they cost in traceability · The rule about rebasing shared branches, and its real reason
The module people remember. Why conflicts happen and what the markers mean, rename and binary conflicts, merge strategies and options, rerere; then recovery — reflog, dangling objects, fsck, and undoing a reset, a rebase or a force-push after the fact.
Topics: Conflict markers, ours and theirs, and what each really refers to · Rename detection, binary conflicts and merge drivers · Merge strategies and strategy options · rerere for repeated conflicts on long-lived branches · reflog: what it records and how long it lasts · fsck, dangling commits and recovering deleted branches · Recovering after a force-push over someone else's work
How two repositories agree. Remotes and refspecs, fetch versus pull, tracking branches, what push refuses and why, force-with-lease, tags and their propagation, and the collaboration patterns that follow from all of it.
Topics: Remotes, refspecs and remote-tracking branches · fetch, pull, pull --rebase and the merge commits nobody wanted · Non-fast-forward rejection and force-with-lease · Tags: lightweight, annotated, signed and pushing them · Shallow clone, single-branch and CI checkout cost · Fork-and-pull versus shared-repository workflows
The high-risk operation done properly. filter-repo for rewriting at scale, removing a leaked credential or a large file from every commit, rewriting author metadata, and the coordination plan — rotation, forks, open branches, caches and mirrors — that has to accompany it.
Topics: git filter-repo versus filter-branch and BFG · Removing a file or a secret from all history · Rewriting authorship and normalising line endings · What a rewrite does to every existing clone and fork · Rotation first: why the credential is compromised regardless · Coordinating a rewrite across teams and CI · Preventing recurrence with secret scanning and hooks
Making Git work where it was not designed to be comfortable. Partial clone, sparse checkout, worktrees, commit-graph and maintenance; Git LFS for binaries; splitting or joining repositories; and migrating from Subversion, Perforce or ClearCase with history intact.
Topics: Partial clone, blobless and treeless clones · Sparse checkout and sparse index for monorepos · Worktrees for parallel work without re-cloning · commit-graph, maintenance and repack tuning · Git LFS: pointers, storage, migration and its limits · Splitting a repository with filter-repo, and subtree joins · Migrating from Subversion, Perforce or ClearCase with branch and tag mapping
The organisational half. Trunk-based development, release branches and GitFlow compared against real release cadence; feature flags as an alternative to long-lived branches; review as a measurable queue; and enforcement through protected branches, required checks, signed commits and CODEOWNERS.
Topics: Trunk-based, GitFlow and release branching, matched to cadence · Long-lived branches across timezones and how to shorten them · Feature flags instead of branch-based isolation · Review latency as a delivery metric · Protected branches, required checks and CODEOWNERS · Signed commits, verified history and audit expectations · Commit message conventions and automated changelogs
Where Git meets the pipeline. Client-side and server-side hooks, pre-commit frameworks that developers tolerate, checkout strategy and cost in CI, submodules and monorepo build triggering, bisect for finding a regression, and the everyday tooling that saves hours.
Topics: Client hooks, server hooks and pre-receive policy · pre-commit frameworks, linting and secret scanning · CI checkout depth, caching and cost per build · Submodules and subtrees in a pipeline · Change detection for monorepo build triggering · git bisect, including automated bisect runs · blame, log pickaxe and archaeology on a real defect
We rebuild the agenda around the tools you actually run.
Request a custom agendaCreate blobs, trees and a commit using plumbing commands alone, move a ref to it, and check it out — then inspect the packfile that results after garbage collection.
Destroy work with reset --hard, a botched interactive rebase and a force-push over a colleague's branch, then recover every piece using reflog and fsck.
Resolve a rename-plus-edit conflict correctly on a long-lived branch, then make the resolution repeat automatically with rerere across three subsequent merges.
Rewrite an entire history with filter-repo to remove a leaked key, produce the rotation and coordination checklist, and verify every fork and CI cache is accounted for.
Take a repository with large binaries and a long history: migrate assets to LFS, enable partial clone and sparse checkout, run maintenance, and measure clone and checkout time.
Import a Subversion or Perforce repository with branch, tag and author mapping preserved, validate the result against the source, and publish a cutover plan for the team.
Two things make Git training in Bangalore different from a generic version-control course. The first is the timezone geometry. A very large number of engineering teams here work on a codebase whose other half sits eight to twelve hours away, and the practical consequence is branch lifetime: work started in Bangalore is reviewed while Bangalore sleeps, so branches live longer, diverge further and merge worse than they do in a co-located team. The questions that come up are therefore about history rather than commands — how to rebase a branch that has been rewritten under you, how to recover a colleague's work after a bad reset, how to keep a shared integration branch usable when reviews arrive in a burst at 22:00 IST.
The second is the sheer amount of legacy version control still in service in this city. Aerospace and avionics engineering, telecom and networking R&D, semiconductor design and long-lived enterprise products all keep repositories in Subversion, Perforce or ClearCase, and the migration work — preserving history, mapping branches and tags, handling multi-gigabyte binary assets that were never meant for a distributed system — lands on Bangalore platform teams. That is where Git LFS, partial clone, sparse checkout and repository splitting stop being trivia. Alongside it sits a compliance thread: BFSI and healthcare groups here need signed commits, protected branches, enforced review and a credible answer when a credential is found in ten-year-old history. Bangalore job specs rarely list Git as a skill on its own, but every platform, release and developer-productivity role in the city is quietly expected to own exactly these problems.
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.
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.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
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.
| 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.