Git vs GitHub Interview Questions (Key Differences Explained with Answers) – 2026 Guide

By Kedar Salunkhe  ·  Updated January 2026  

Git vs Github Interview Questions. This is one of those questions that separates candidates in the first two minutes of an interview.

“What is the difference between Git and GitHub?”

It sounds simple. And the honest answer is simple. But you would be surprised how many candidates — including people who have been using both for a year or more — either fumble it or give an answer that is technically half-right but reveals they never really understood the distinction.

The confusion usually comes from how people learn these tools. You search for “how to save code online,” you find GitHub, you follow a tutorial that involves Git commands, and everything blurs together into one concept called “GitHub” that involves typing git in a terminal. The underlying distinction never gets made explicit.

This guide makes it explicit. We cover the core difference, every related interview question you are likely to face, the differences that go deeper than the surface answer, and the GitHub-specific features that come up in their own right during interviews. Every answer here is written to sound like something a real developer would say — not a copied paragraph from documentation.

By the time you finish this, the Git vs GitHub question will not just be answerable. It will feel obvious.

1. The Core Difference: What Every Interviewer Wants to Hear

Before getting into individual questions, let’s establish the foundation clearly — because everything else in this guide builds on it.

Git is a tool. GitHub is a service.

Git is a free, open-source version control system created by Linus Torvalds in 2005. You install it on your computer. It runs locally. It tracks changes to files, manages branches, stores commit history, and lets you work on code without an internet connection. Git does not know about GitHub. It does not require GitHub. It has existed independently since before GitHub was created.

GitHub is a cloud-hosted platform built on top of Git. It stores Git repositories online so they can be shared, backed up, and collaborated on. GitHub adds features that Git itself does not have: Pull Requests, Issues, Actions for automation, a web interface for browsing code, team permissions, and project management tools. GitHub was founded in 2008, is owned by Microsoft since 2018, and is one of several platforms that host Git repositories.

The analogy that lands best in interviews:

Git is like Microsoft Word. GitHub is like Google Drive. You use Word to write documents. You use Google Drive to store and share them. Word works perfectly without Google Drive. Google Drive doesn’t write documents on its own. They work together, but they are completely separate things with separate purposes.

With that foundation established, every question in this guide becomes answerable with clarity.

2. Git-Specific Interview Questions

These are questions about Git itself — the tool, not the platform. Answers here should be free of any GitHub references unless specifically comparing the two.

Q1. What is Git and why was it created?

Git is a distributed version control system that tracks changes to files over time and enables multiple people to collaborate on the same codebase without overwriting each other’s work.

It was created in 2005 by Linus Torvalds specifically to manage the Linux kernel’s development. The kernel team had been using a proprietary version control system called BitKeeper, but when that relationship broke down, Torvalds evaluated what was available and found nothing that met his requirements for speed, distributed design, and data integrity. He built Git himself in about two weeks. The Linux kernel project switched to Git almost immediately, and within a few years Git had become the default choice across the software industry.

Q2. What makes Git “distributed”?

In older centralised version control systems like SVN, there is one central server that holds the official repository. Developers check files out from it, make changes, and check them back in. If the server goes down, no one can work. If the server is destroyed, the history is gone.

Git is distributed because every developer who clones a repository gets a complete, fully functional copy of the entire project on their own machine — not just the current files but every commit, every branch, the full history going back to day one. You can make commits, create branches, view history, and switch versions entirely offline. When you push to a remote server, you are synchronising your local copy with a shared copy — not checking files in and out of a central authority.

This means if any server disappears, every developer’s local copy is a complete backup. And it means Git operations are fast because most of them require no network connection.

Q3. What are the core objects Git stores?

Git stores four types of objects in its internal database:

• Blob — the raw content of a file, without any metadata like filename or permissions
• Tree — a directory listing that maps filenames and permissions to blobs or other trees
• Commit — a snapshot pointing to a root tree, with author info, timestamp, message, and a pointer to the parent commit
• Tag — an annotated reference to a specific commit with its own metadata

Every object is identified by a SHA-1 hash computed from its content. The same content always produces the same hash, which is how Git guarantees that nothing in its history is ever silently corrupted.

Q4. Does Git require an internet connection?

No. Git is designed to work completely offline. You can make commits, create and switch branches, view history, diff files, merge branches, and do interactive rebases with no network connection whatsoever. The only Git operations that require a network are those that communicate with a remote server: git clone, git fetch, git pull, and git push.

This is one of the significant advantages over older centralised systems where even basic operations like viewing history required a server connection.

Q5. Is Git free to use?

Yes, completely. Git is free and open-source software released under the GNU General Public License version 2. There is no paid version, no enterprise tier, no licensing cost. It is maintained by a community of contributors and backed by organisations including Google and Microsoft. You can download it, use it for any purpose, and inspect or modify the source code freely.

3. GitHub-Specific Interview Questions

GitHub has its own set of features that exist on the platform and not in Git itself. These are common interview questions in their own right, especially for roles that involve collaboration and CI/CD workflows.

Q6. What is GitHub and what does it add on top of Git?

GitHub is a cloud-hosted platform for storing and collaborating on Git repositories. You push your local Git repository to GitHub so it is backed up online, accessible from any machine, and shareable with teammates or the public.

Beyond storage, GitHub adds features that Git itself does not have:

• Pull Requests — a structured process for proposing, reviewing, and merging code changes
• Issues — a built-in bug tracker and task management system
• GitHub Actions — automation workflows triggered by repository events, used for CI/CD
• Code review tools — inline comments on specific lines, review approvals, requested changes
• Branch protection rules — prevents direct pushes to important branches, requires reviews before merging
• Forks — personal copies of someone else’s repository, used for open-source contributions
• GitHub Pages — static website hosting directly from a repository
• Security alerts — automated scanning for vulnerable dependencies
• Insights and analytics — contribution graphs, traffic data, code frequency charts

Q7. What is a Pull Request and is it a Git feature?

A Pull Request is not a Git feature. It is a GitHub feature — and a very important distinction to make clearly in interviews.

Git itself has no concept of a Pull Request. Git knows about branches and merges. A Pull Request is a workflow layer that GitHub built on top of Git’s branching model. When you open a Pull Request, you are telling GitHub: here is a branch I want to merge into another branch, please show the team the diff and give us a place to discuss and review it.

GitLab calls the same concept a Merge Request. Bitbucket also calls them Pull Requests. The name differs but the concept is identical: a hosted code review mechanism built on top of Git branching.

Q8. What is a fork on GitHub?

A fork is a personal copy of someone else’s GitHub repository, created under your own GitHub account. It is a GitHub concept, not a Git concept — Git has no idea what a fork is.

Forking is the standard workflow for contributing to open-source projects. When you do not have write access to a repository, you fork it. This gives you your own copy where you have full permissions. You clone your fork locally, create a branch, make changes, push the branch to your fork, and then open a Pull Request from your fork’s branch to the original repository’s main branch. The original repository maintainers review your PR and decide whether to merge it.

When working with a fork, you typically set up two remotes locally:

# origin points to your fork
$ git remote add origin https://github.com/yourusername/project.git

# upstream points to the original repository
$ git remote add upstream https://github.com/originalowner/project.git

# Keep your fork updated with the original
$ git fetch upstream
$ git checkout main
$ git merge upstream/main

Q9. What is GitHub Actions?

GitHub Actions is GitHub’s built-in CI/CD and automation platform. You define workflows in YAML files stored in the .github/workflows/ directory of your repository. These workflows are triggered by events — a push to main, a Pull Request being opened, a release being published, a scheduled cron timer, or a manual trigger.

A typical workflow runs automated tests on every Pull Request, reports whether they pass, and prevents merging if they fail. More advanced workflows build and deploy applications, publish packages to registries, send notifications, run security scans, or update documentation automatically.

# .github/workflows/test.yml
name: Run Tests

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install
      - run: npm test

GitHub Actions competes with external CI/CD tools like Jenkins, CircleCI, and Travis CI. Its advantage is tight integration with the repository — access to code, secrets, issues, and PR context without extra configuration.

Q10. What are branch protection rules on GitHub?

Branch protection rules are settings on a GitHub repository that control what can happen to specific branches. They enforce your team’s workflow automatically rather than relying on everyone remembering to follow conventions manually.

On a properly configured team repository, main would typically have rules that require at least one reviewer to approve before merging, require all CI checks to pass, require the branch to be up to date with main before merging, and prevent direct force-pushes or deletion of the branch.

The result is that broken code literally cannot reach main if the tests catch it, and no one — not even the repository owner — can push to main without a reviewed Pull Request. These rules are set in GitHub repository settings under Branches and are a GitHub feature, not a Git feature.

Q11. What is GitHub Pages?

GitHub Pages is a free static website hosting service built into GitHub. You can deploy a website directly from a repository by pointing GitHub Pages at a branch or a folder. GitHub builds and serves the site automatically.

It is commonly used for portfolio websites, project documentation, open-source project landing pages, and personal blogs built with static site generators like Jekyll or Hugo. The site URL is typically username.github.io or username.github.io/repository-name, and you can configure a custom domain.

This is entirely a GitHub feature. Git has no concept of web hosting.

4. Direct Comparison Questions

These are the questions that explicitly ask you to compare Git and GitHub. They come up in almost every interview that mentions either tool and they reward a clear, structured answer.

Q12. Can you use Git without GitHub?

Yes, entirely. Git is a local tool that works without any remote server. You can initialise a repository, make commits, create branches, merge, rebase, and maintain a complete version history with no internet connection and no GitHub account. Many internal enterprise projects use Git with private servers that have nothing to do with GitHub.

The things you lose without a remote hosting service are: off-machine backup, sharing your repository with others, and collaboration features like Pull Requests. But the core version control functionality — tracking history, branching, undoing changes — is all local.

Q13. Can you use GitHub without knowing Git?

Technically yes — GitHub has a web interface where you can create files, edit them, commit changes, and even merge Pull Requests without ever touching the command line. For very simple tasks this works.

Practically speaking, no. The moment any real development work is involved — working locally, running tests, resolving conflicts, managing multiple branches in a complex codebase — you need Git. GitHub’s web interface is a convenience layer on top. The underlying model is Git and trying to use GitHub seriously without understanding Git leads to confusion quickly.

Q14. What is the difference between a Git remote and GitHub?

A Git remote is any reference to a repository stored somewhere other than your local machine. It is a concept within Git itself. You add a remote with git remote add and push or pull from it with git push and git pull.

GitHub is one possible place where that remote repository lives. But a remote could equally point to a server in your company’s data centre, a repository on GitLab, a repository on another developer’s machine on your local network, or a bare repository on a USB drive. GitHub is an implementation of where a remote can be hosted — it is not synonymous with “remote.”

# A remote can point to GitHub
$ git remote add origin https://github.com/username/project.git

# Or to a company's internal GitLab server
$ git remote add origin https://gitlab.company.com/team/project.git

# Or to another folder on your own machine
$ git remote add local-backup /home/rohan/backups/project.git

# Git does not care where the remote is — all are handled the same way

Q15. What does git push actually do with respect to GitHub?

git push is a Git command that sends commits from your local repository to a remote repository. When that remote happens to be GitHub, Git connects to GitHub’s servers over HTTPS or SSH and transfers the commit objects that the remote does not already have. GitHub stores those objects and updates its copy of the branch to point to your latest commit.

From Git’s perspective, it does not know or care whether the remote is GitHub, GitLab, a private server, or anything else. It is just communicating with a remote using Git’s transfer protocol. GitHub is on the receiving end running the same Git internals that you have locally.

Q16. What is the difference between a commit in Git and a commit on GitHub?

They are the same thing. A commit is a commit — a Git object with a SHA-1 hash, snapshot, author info, and parent pointer. When you push your local commits to GitHub, those same commit objects are transferred to GitHub’s servers. GitHub displays them through its web interface with additional formatting, links to diffs, and navigation, but the underlying data is the same Git commit object.

You create commits locally using Git. You view them on GitHub through a web UI. GitHub does not create different types of commits — it just hosts and displays the ones Git creates.

Q17. What is the difference between git merge and a GitHub Pull Request merge?

git merge is a Git command that combines branch histories locally. When you merge, Git does the work on your machine and you end up with a local commit that you then push.

A Pull Request merge on GitHub is triggered through GitHub’s web interface after a code review process. When you click the merge button on a PR, GitHub runs a git merge (or squash merge or rebase merge, depending on the option chosen) on its servers and pushes the resulting commit to the remote branch. It is still a Git merge underneath — GitHub is just running it in the cloud and wrapping it in a review workflow.

GitHub offers three merge options for Pull Requests:

• Create a merge commit — standard git merge --no-ff, preserves full branch history
• Squash and merge — combines all PR commits into one commit on main, equivalent to git merge --squash
• Rebase and merge — replays PR commits linearly on top of main, equivalent to git rebase followed by a fast-forward merge

5. GitHub vs GitLab vs Bitbucket

Interviews for DevOps roles in particular often ask about the ecosystem of Git hosting platforms. Knowing the honest differences between them is more useful than being able to recite marketing points.

Q18. What is the difference between GitHub and GitLab?

Both host Git repositories and offer similar core features: Pull/Merge Requests, Issues, CI/CD pipelines, branch protection, and web-based code review.

The meaningful differences:

GitLab is a more complete DevOps platform out of the box. Its built-in CI/CD (GitLab CI) is considered more mature and flexible than GitHub Actions by many DevOps teams. GitLab can be self-hosted on your own infrastructure, which makes it popular in enterprises with strict data residency or compliance requirements. It is open-source at its core.

GitHub has a larger community and is the dominant platform for open-source projects. The discoverability of public repositories, the size of the community, and the GitHub-specific workflows most developers know (forking, starring, following) make it the default for public work. GitHub Copilot, GitHub Codespaces, and GitHub’s integration with the Microsoft ecosystem are differentiators in 2026.

The naming difference — Pull Requests on GitHub vs Merge Requests on GitLab — is the most common specific comparison interviewers ask about. They are the same concept, just named differently.

Q19. What is Bitbucket and how does it differ from GitHub?

Bitbucket is Atlassian’s Git hosting platform. It does the same core job as GitHub and GitLab. Its primary differentiator is deep integration with the rest of the Atlassian suite — particularly Jira for issue tracking and Confluence for documentation. Companies that are already heavily invested in Atlassian tools often choose Bitbucket because the integration is tight and the workflow between code commits and Jira tickets is seamless.

Bitbucket was one of the first platforms to offer free private repositories, which gave it early traction with small teams. GitHub and GitLab have since matched this. Bitbucket’s community and public repository ecosystem is much smaller than GitHub’s, which makes it a less common choice for open-source work.

Q20. Which one should a team choose?

The honest answer depends on the context:

• Open-source project or anything that benefits from community visibility: GitHub
• Team that wants a complete self-hosted DevOps platform with strong built-in CI/CD: GitLab
• Team already using Jira, Confluence, and the Atlassian ecosystem: Bitbucket
• Team with strict compliance requirements needing on-premises hosting: GitLab self-hosted or Bitbucket Data Center

In practice, most individual developers and small teams default to GitHub because of its community size, documentation quality, and the fact that most tutorials assume GitHub. The underlying Git is identical across all three platforms — switching between them is a matter of updating remote URLs and learning the platform-specific UI.

6. Workflow and Collaboration Questions

These questions are about how Git and GitHub work together in a real team environment. They test whether you understand the collaboration model, not just the individual tool definitions.

Q21. Walk me through how a developer contributes to an open-source project on GitHub.

The standard open-source contribution workflow:

1. Fork the repository on GitHub — this creates your own copy under your account
2. Clone your fork to your local machine with git clone
3. Add the original repository as a second remote called upstream
4. Create a branch for your contribution — git checkout -b fix/typo-in-readme
5. Make your changes locally, commit with a clear message
6. Push the branch to your fork — git push -u origin fix/typo-in-readme
7. Open a Pull Request on GitHub from your fork’s branch to the original repository’s main branch
8. Respond to feedback from maintainers, pushing additional commits to the same branch
9. Once approved, a maintainer merges the PR

The fork and PR model exists because contributors do not have write access to projects they do not own. Forking gives them a space where they have full permissions to work, and the PR provides a channel through which they can propose changes to the original without being able to push directly.

Q22. What is the difference between a fork and a branch?

A branch is a Git concept — a lightweight pointer to a commit that lets you work on a separate line of development within the same repository. Branches live inside one repository and are shared between everyone who has access to it.

A fork is a GitHub concept — a complete copy of a repository under a different account. The fork is a separate repository that shares no direct connection with the original except its origin history. Forks are used when you want to work on a copy of a repository that you do not own.

On a team where everyone has write access to the same repository, you use branches. In open-source where contributors do not have write access, they use forks. The combination of forking and PR is GitHub’s solution to the access control problem that Git’s branching alone does not solve.

Q23. How does code review work on GitHub?

When a developer opens a Pull Request on GitHub, the PR shows the complete diff of every file changed in the branch versus the target branch. Reviewers can leave comments in three ways: a general comment on the entire PR, a line comment on a specific line of the diff, or a suggestion — an inline proposed change that the author can accept with one click.

A reviewer can submit three types of reviews: Comment (feedback without a verdict), Approve (the PR is good to merge), or Request Changes (must be addressed before this reviewer approves). With branch protection rules, a PR can be configured to require a minimum number of approvals before the merge button becomes available.

When the author pushes new commits to the branch in response to feedback, those commits automatically appear in the PR and update the diff. Reviewers can see which comments have been addressed. Once all requested changes are resolved and sufficient approvals are given, the PR is merged.

Q24. What is the difference between git fetch and git pull in the context of working with GitHub?

git fetch origin downloads any new commits, branches, and tags from GitHub to your local machine and updates your remote-tracking branches — your local record of where GitHub’s branches currently are. Your actual working files and local branches are not touched.

After fetching, you can run git log origin/main --oneline to see what your teammates pushed without having merged anything yet. This is useful before you decide how to integrate the changes.

git pull does a fetch followed immediately by a merge into your current branch. It is faster but gives you less control — you are merging without necessarily having reviewed what is coming in. On active projects where conflicts are possible, fetching first and reviewing before merging is the more careful approach.

Q25. What happens to a Pull Request if you push more commits to the branch?

The PR updates automatically. GitHub tracks the branch, not a static snapshot. When you push new commits to the branch that the PR is based on, those commits appear immediately in the PR’s commit list and the diff updates to reflect the latest state of the branch versus the target branch.

This is how you respond to code review feedback. The reviewer asks you to change something, you make the change locally, push to the same branch, and the PR shows the new commit. The reviewer can re-review and see exactly what changed since their last review. No need to close the PR and open a new one.

7. Advanced GitHub Features Worth Knowing

These features come up in interviews for roles where GitHub is central to the workflow — DevOps, senior developer, and platform engineering roles in particular.

Q26. What is GitHub Copilot?

GitHub Copilot is an AI-powered code completion tool developed by GitHub and OpenAI. It integrates with code editors like VS Code and JetBrains IDEs and suggests code as you type — completing lines, writing functions, generating tests, and explaining existing code. It is trained on public code repositories.

Copilot is a paid GitHub service, not part of Git itself. It is relevant to interviews because it represents a significant shift in how many developers work with repositories hosted on GitHub, and questions about AI-assisted development are increasingly common in 2026.

Q27. What is GitHub Codespaces?

GitHub Codespaces is a cloud-based development environment hosted by GitHub. You can spin up a full VS Code development environment in a browser, pre-configured for a specific repository, in under a minute. No local setup required — the code, dependencies, tools, and terminal are all in the cloud.

It is used for onboarding new team members quickly, contributing to projects without setting up a local environment, and working from any device. Under the hood, each Codespace is a Docker container running in Azure and the code is your actual repository cloned into it — it is still Git and GitHub, just with the development environment included.

Q28. What is a GitHub Gist?

A GitHub Gist is a simple way to share a single file or small snippet of code. Each Gist is a minimal Git repository — it has history, can be forked, and can be cloned. But unlike a full repository, a Gist is designed for sharing a single piece of content: a script, a configuration snippet, a code example, or a note. Gists can be public or secret (not truly private — anyone with the URL can see them, they just do not appear in search).

Q29. What are GitHub Releases?

GitHub Releases is a feature for packaging and distributing software versions. A Release is built on top of a Git tag — you create a Release from a tag and attach compiled binaries, documentation, and release notes to it. Users can download the release assets directly from GitHub without needing to clone the repository and build from source.

Releases represent the public distribution story. The underlying code history is Git. The tag marking the release point is Git. The packaging, release notes editor, and asset uploading are GitHub features built on top.

Q30. What is a GitHub token and when would you use one?

A GitHub Personal Access Token (PAT) is an authentication credential that you use instead of a password when authenticating to GitHub from the command line or in automated workflows. Since GitHub deprecated password authentication for Git operations in 2021, tokens are the standard way to authenticate HTTPS-based pushes and pulls.

Tokens can be scoped — you grant them specific permissions like repository access, workflow permissions, or read-only access — and they have expiration dates. In CI/CD pipelines, the GITHUB_TOKEN is an automatically generated token available in GitHub Actions workflows that has permissions to interact with the repository. Fine-grained PATs introduced in 2022 allow even more precise permission control at the individual repository level.

Frequently Asked Questions

Related Resources

For going deeper on Git, GitHub, and interview preparation:

• Pro Git (Free Book) — The definitive Git reference. Chapters 1 and 2 cover Git fundamentals without any GitHub dependency, which is exactly the distinction this guide is built on.
• GitHub’s Official Overview of Git and GitHub — GitHub’s own explanation of how Git and GitHub relate. Worth reading once to see how the platform itdifferences.

More on this site:

• GIT
• Git Internals Explained: How Git Works Behind the Scenes (Step-by-Step Guide) [2026]
• What is Git? Beginner Guide (With Real Examples) [2026]

Final Thoughts

The Git vs GitHub distinction is one of those things that feels trivial once you understand it but reveals a real gap when you do not. Interviewers ask it not because the answer is complicated, but because it is an efficient signal. A candidate who genuinely understands the difference gives an answer that is clear, confident, and naturally extends into related territory. A candidate who has only used the two together without thinking about them separately gives an answer that is vague, conflates the concepts, or stalls.

The foundation is simple: Git is a local version control tool. GitHub is a cloud platform that hosts Git repositories and adds collaboration features on top. Everything else in this guide builds from that.

Know the features that belong only to GitHub — Pull Requests, forks, Issues, Actions, branch protection rules, Codespaces — and be clear that these are platform features, not Git features. Know which operations require the network (anything involving a remote) and which do not (everything else). Know the three merge options GitHub offers for PRs and what each one does to the history. Know the two-remote pattern for open-source contribution.

If you have used both tools on real projects, explaining the difference will feel natural because you have experienced it. If you have mostly used GitHub’s web interface, spend some time working with Git from the command line on a local repository that has no remote at all. That experience — Git working perfectly offline, managing real history, with no GitHub involved — makes the distinction concrete in a way that reading about it cannot fully replicate.

About the Author

Kedar Salunkhe

DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee

I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.