All roadmaps

Git & GitHub

The one tool every technical career assumes.

From first commit to confident collaboration: core Git, branching and merging, team workflows, history surgery and the GitHub layer of PRs, reviews and automation.

Your progress0/36 topics · 0%

Progress is saved in this browser.

5 stages36 topics₹0 to follow
Skill certification coming soon

Filled nodes are the focus for this track; outlined ones can wait. Tap a topic to open it and mark it done, learning or skipped.

Git & GitHub in 2026Related roadmapsDocker roadmapDevOps roadmapClaude Code roadmapProve it as you goMark topics done, learning or skipped asyou go; your progress is saved in thisbrowser and carries into the classicview. The Git & GitHub in 2026 section atthe top says what to learn first and whathiring teams check.Job simulationClassic viewKnow the demand before thesyntaxGit & GitHub in 2026What to learn in 2026Branches andhistoryPRs, reviews,ActionsCopilot on GitHubWhich roles use itEvery developerOpen source asproofFresher vs switcherWhat companies expectThe hiring barWhat interviewstestProof they verifyWhat gets you hiredA 90-day planProjects thatget readCertification and proofA mental model, not memorisedcommands.Git FundamentalsHow Git thinksEveryday commandsUndoing thingsgitignore & configurationParallel work without fear.Branching & MergingBranchesMerge vs rebaseResolving conflictsStash & worktreesThe team layer.GitHub CollaborationRemotes, push & pullPull requests & reviewsIssues & projectsOpen-source contributionHistory surgery and automation.Power UserInteractive rebase &cherry-pickbisect & blameGitHub Actions basicsFresher or experienced?Both tracks hold every topic. On the Fresher track thefoundations are filled and the later stages are outlined - dothem when a project needs them. On the Experienced track thefoundations are outlined and the later stages are filled. The2026 section at the top applies to both.Prefer a list?The classic view shows the same 4 stages as a sequentialchecklist with time estimates. Your marks are shared betweenthe two views.Open the classic view

Everything on this roadmap

Every stage and topic on the map, in reading order. Click any topic to open it.

The Git & GitHub roadmap, topic by topic

Every topic on the map in reading order, with what to learn and the resources we recommend. Main topics are open; open any subtopic to read it. Select a topic name to open it in the topic panel, where you can track your progress.

  1. 1. Know the demand before the syntax

    Git & GitHub in 2026

    2026

    Git is how every team keeps and reviews its code, and in 2026 GitHub is where more than 180 million developers keep theirs. GitHub's Octoverse 2025 report counted 36 million new developers in a year - one every second - with India the largest source at more than 5.2 million and, for the first time, the largest base of open-source contributors ahead of the United States; it also counted 630 million repositories, 4.3 million of them AI-related, and found 80 percent of new developers using Copilot in their first week. The four nodes answer what to learn, which roles use it, what companies expect and what gets you hired.

    What to learn in 2026

    Learn Git's model and the daily commands until branching, merging, rebasing and recovering from mistakes are reflexes, then the GitHub workflow - pull requests, reviews, Actions, releases - and then the AI layer that now lives inside both. The sub-nodes order the three.

    Branches and history

    Git is a graph of commits, and everything else follows from that: branches as pointers, merging versus rebasing, the staging area, how to inspect history, how to find what changed and when, and how to recover - reflog, reset, revert, stash - when something goes wrong. The Octoverse 2025 report's one new developer per second all learn the same model, and the ones who understand it stop fearing the command line. Practise on your own project until a rebase, a conflict and an accidental commit are each a one-minute fix.

    PRs, reviews, Actions

    Teams work through GitHub's workflow: a branch per change, a pull request that explains what and why, a review with comments addressed, checks that run in Actions - tests, linting, builds, security scans - and a merge that keeps history readable. Then releases, tags, issues and projects for the work around the code. Octoverse 2025 counts 630 million repositories using this flow; a learner who can open a clean pull request against a stranger's project has the skill. The DevOps roadmap carries Actions deeper into deployment.

    Copilot on GitHub

    AI

    AI now sits inside the workflow: Copilot completes and explains code in the editor, reviews pull requests, summarises changes and can take an issue and open a pull request itself; GitHub reports 80 percent of new developers using it in their first week. The Stack Overflow 2025 survey's 46 percent distrust figure applies here too - the generated pull request still needs a human reviewer who reads the diff. The skill employers want is the review habit: small, readable changes, generated or not, with a message that says why and tests that say it works.

    Which roles use it

    Every developer needs Git; open-source contribution on GitHub is the most verifiable proof of skill a learner can build. The sub-nodes cover both and the fresher and switcher routes.

    Every developer

    There is no developer role without Git: frontend, backend, data, DevOps, mobile and AI engineers all branch, commit, review and merge every day, and most data analysts and technical writers do too. Octoverse 2025's 180 million developers is the measure. The difference between a junior and a senior shows in the history they leave - small commits, clear messages, pull requests that teach - which is why interviewers read your repositories before they read your resume.

    Open source as proof

    Open source is the most verifiable proof of skill available: a merged pull request on a real project shows you can read unfamiliar code, follow a team's conventions and get a change through review. Octoverse 2025 found India the largest source of new developers and, for the first time, the largest base of open-source contributors, so the path is well worn. Start with documentation and small fixes on a project you use, learn its contributing guide, and make your profile show the merged work.

    Fresher vs switcher

    A fresher should make their GitHub profile the portfolio: real commit history on their projects, a pinned deployed application, a merged contribution and a readme on each; HackerRank's 2025 report found early-career hiring the hardest hit with 74 percent of developers struggling, and a readable profile is the differentiator reviewers actually use. A switcher from another version-control system should learn Git's graph model rather than map commands. On this map freshers get the basics filled and the advanced history stages outlined; experienced learners get the reverse.

    What companies expect

    Companies expect clean, reviewable history: small commits with clear messages, branches that merge without drama, pull requests that explain themselves, and a repository a new teammate can read. The sub-nodes cover the bar, the interview and what gets verified.

    The hiring bar

    The bar is history a teammate can read: a branch per change, commits that each do one thing with a message that says why, pull requests with a description and tests, review comments addressed rather than argued, and no secrets or build artefacts in the repository. The Work Trend Index found 66 percent of leaders unwilling to hire without AI skills; on GitHub that means using Copilot and still being the person whose name is on a diff they understood.

    What interviews test

    Expect to be asked how you would recover from a bad commit, resolve a conflict, keep a branch up to date, review a pull request and set up a check in Actions; some teams give a small repository with a task and watch the history you leave. HackerRank's 2025 report says 66 percent of developers prefer practical assessments and that they are now the standard. Your own repositories are the real interview - make them readable before you apply.

    Proof they verify

    Reviewers open your profile and read: pinned repositories with readmes, recent real commits, pull requests you opened and reviewed, and a contribution on a project that is not yours. That beats any Git course badge. Pair it with a verified certification for the skill the repository demonstrates - OneRoadmap's are free and carry a public verification link - and a short note on how you use AI tools in your workflow.

    What gets you hired

    A GitHub profile a reviewer can read in a minute - real commit history, a pinned project, a merged contribution - is the proof that outlasts any resume line. The sub-nodes give the ninety-day plan, the projects that get read and the proof that counts.

    A 90-day plan

    Month one: Git's model and daily commands on your own project, with history cleaned up and every mistake practised and recovered from. Month two: the GitHub workflow - branches, pull requests, reviews and Actions with tests - on that project, plus a first documentation contribution to an open-source project you use. Month three: a merged code contribution, Copilot used and reviewed in your workflow, pinned repositories with readmes, and twenty targeted applications a week with the profile linked.

    Projects that get read

    Projects that get read show the workflow, not just the code: a repository with a clean history, a pull request template, Actions that run tests on every push, releases with notes and a contributing guide; a merged pull request on a known open-source project; a small tool with issues triaged and a changelog. Octoverse 2025's 630 million repositories mean the ones that stand out are the ones that look maintained.

    Certification and proof

    Proof is the profile itself: real commits over months, pull requests reviewed and merged, a contribution outside your own work, and a pinned deployed project. With India the largest source of new developers on GitHub in Octoverse 2025, a profile that shows discipline is how a reviewer separates one candidate from the next in a minute.

  2. 2. A mental model, not memorised commands.

    Git Fundamentals

    A mental model, not memorised commands.

    Time: about 1 week. Topics: How Git thinks · Everyday commands · Undoing things · gitignore & configuration.

    How Git thinks

    Optional on the Experienced track

    Snapshots, the three states (working/staging/committed) and the DAG - the model that makes every command obvious.

    Everyday commands

    Optional on the Experienced track

    init, add, commit, status, log, diff - the loop you'll run thousands of times.

    Undoing things

    Optional on the Experienced track

    restore, revert, reset (soft/mixed/hard) and reflog - Git as a safety net, not a threat.

    gitignore & configuration

    Optional on the Experienced track

    Keeping secrets and noise out of history; aliases and sane defaults.

  3. 3. Parallel work without fear.

    Branching & Merging

    Parallel work without fear.

    Time: about 1 week. Topics: Branches · Merge vs rebase · Resolving conflicts · Stash & worktrees.

    Branches

    Cheap pointers, not copies - feature branches as the default unit of work.

    Merge vs rebase

    Preserving vs rewriting history, and the golden rule of never rebasing shared branches.

    Resolving conflicts

    Reading conflict markers calmly, using diffs and testing after resolution.

    Stash & worktrees

    Parking work-in-progress and running parallel checkouts - context switching without chaos.

  4. 4. The team layer.

    GitHub Collaboration

    The team layer.

    Time: about 1 week. Topics: Remotes, push & pull · Pull requests & reviews · Issues & projects · Open-source contribution.

    Remotes, push & pull

    origin/upstream, fetch vs pull and tracking branches - syncing without surprises.

    Pull requests & reviews

    Small focused PRs, review etiquette and protected branches - how software actually merges.

    Issues & projects

    Tracking work next to code - the lightweight PM layer teams standardise on.

    Open-source contribution

    Fork → branch → PR etiquette, and finding good first issues - a public track record.

  5. 5. History surgery and automation.

    Power User

    History surgery and automation.

    Time: about 1 week. Topics: Interactive rebase & cherry-pick · bisect & blame · GitHub Actions basics.

    Interactive rebase & cherry-pick

    Optional on the Fresher track

    Squashing, reordering and porting commits - clean history as communication.

    bisect & blame

    Optional on the Fresher track

    Binary-searching history for the breaking commit - debugging with time travel.

    GitHub Actions basics

    Optional on the Fresher track

    Tests on every PR from a YAML file - your first taste of CI.

Prove it as you go

Mark topics done, learning or skipped as you go; your progress is saved in this browser and carries into the classic view. The Git & GitHub in 2026 section at the top says what to learn first and what hiring teams check.

Fresher or experienced?

Both tracks hold every topic. On the Fresher track the foundations are filled and the later stages are outlined - do them when a project needs them. On the Experienced track the foundations are outlined and the later stages are filled. The 2026 section at the top applies to both.

Prefer a list?

The classic view shows the same 4 stages as a sequential checklist with time estimates. Your marks are shared between the two views.

Frequently asked questions

Why learn Git properly instead of just using the basics?

Because the moment something goes wrong - a bad commit, a conflict, a rebase, a lost branch - the basics are not enough, and because the history you leave is how a team judges you. Git is a graph of commits; understand that and every command becomes predictable instead of frightening.

Is GitHub the same as Git?

No. Git is the version-control tool on your machine; GitHub is the service where more than 180 million developers host their repositories and work through pull requests, reviews, issues and Actions. Learn Git's model first, then GitHub's workflow, then the AI features that now live inside both.

Does my GitHub profile really matter for hiring?

Yes - it is usually read before the resume. Reviewers look for pinned repositories with readmes, real commit history over months, pull requests you opened and reviewed, and a contribution to a project that is not yours. A profile that shows discipline separates one candidate from the next in a minute.

How do I contribute to open source as a beginner?

Start with a project you use, read its contributing guide, fix a documentation gap or a small bug, open a clean pull request and address the review politely. GitHub's Octoverse 2025 found India the largest source of new developers and, for the first time, the largest base of open-source contributors - the path is well worn.

How long does it take to learn Git well?

The daily commands take a day; the model - branches as pointers, merging versus rebasing, the reflog - takes a week or two of using it on your own project until a conflict, a rebase and an accidental commit are each a one-minute fix; the GitHub workflow with pull requests, reviews and Actions a few weeks more. Nobody can promise a timeline. A profile a reviewer can read in a minute is the evidence.

Merge or rebase?

Rebase your own branch to keep it current and readable; merge to bring a reviewed branch into the main line; never rewrite history that others have pulled. Teams have conventions - learn theirs. The interview question is not which is better but whether you understand what each does to the graph.

What are GitHub Actions and do I need them?

Actions is GitHub's automation: tests, linting, builds, security scans and deployments that run on every push or pull request. Every serious repository has at least a test workflow, and setting one up is expected of any developer. The DevOps roadmap takes Actions into full deployment pipelines.

Will AI change how I use Git and GitHub?

It already has: Copilot completes and explains code, reviews pull requests, summarises changes and can take an issue and open a pull request itself. What has not changed is the review - a generated pull request still needs a human who reads the diff. Small, readable, explained changes are the skill, generated or not.

How do I prove Git and GitHub skills without job experience?

Your profile is the proof: repositories with clean history and readmes, a pull request template and Actions that run tests, releases with notes, a merged contribution to a known open-source project, and pinned deployed work. Pair it with a verified OneRoadmap certification for the skill the repositories demonstrate.