Git & GitHub Interview Questions & Answers (2026) – RankWeb3

Git GitHub All Levels 30 Questions Updated 2026

Git & GitHub Interview
Questions & Answers

📅 Updated: March 2026

⏱️ Read time: ~20 min

🎯 30 questions — Beginner to Advanced

✍️ By RankWeb3 Team

Total Questions

Beginner

Intermediate

Advanced

🌱Beginner QuestionsQ1–Q10

What is Git and why do developers use it?

BeginnerVery Common

Git is a free, open-source distributed version control system created by Linus Torvalds in 2005. It tracks changes in source code over time so developers can collaborate, revert mistakes, and maintain a full history of a project.

Version history: Every change is saved — you can go back to any point in time.
Collaboration: Multiple developers can work on the same codebase simultaneously without overwriting each other's work.
Branching: Work on new features in isolation, then merge them when ready.
Distributed: Every developer has a full copy of the repository — no single point of failure.

💡Why interviewers ask this: To confirm you understand what Git actually does, not just how to use a few commands. Mention "distributed" and "version control" explicitly.

What is the difference between Git and GitHub?

BeginnerVery Common

This is one of the most common confusion points for beginners. They are not the same thing:

Git	GitHub
A version control tool installed on your computer	A cloud platform to host Git repositories
Works offline — runs locally	Requires internet — it's a website
Command-line tool	Has a web UI, pull requests, issues, Actions
Created by Linus Torvalds (2005)	Founded 2008, owned by Microsoft since 2018
Free and open-source	Free for public repos, paid plans for teams

Think of Git as the engine and GitHub as the garage where you park and share your car. GitLab and Bitbucket are alternative garages.

What are the basic Git commands every developer should know?

BeginnerVery Common

Bash / Git
# Setup
git config --global user.name  "Your Name"
git config --global user.email "you@example.com"

# Start a project
git init                     # initialise new repo
git clone <url>              # clone remote repo locally

# Daily workflow
git status                   # see what's changed
git add .                    # stage all changes
git commit -m "your message"  # save snapshot
git push origin main         # send to remote
git pull                     # fetch + merge remote changes

# Branching
git branch                   # list branches
git checkout -b feature-x   # create + switch to branch
git merge feature-x          # merge branch into current

# History
git log --oneline             # compact commit history
git diff                     # see unstaged changes

What is a Git repository? What is the difference between a local and remote repository?

Beginner

A Git repository (or "repo") is a folder that Git is tracking. It contains all your project files plus a hidden .git folder that stores the entire version history.

Local repository: Lives on your own machine. You work here — create files, make commits, create branches. Has no internet requirement.
Remote repository: Hosted on a server (GitHub, GitLab, Bitbucket). Acts as the shared source of truth for teams. You push your local changes to it and pull others' changes from it.

Bash
# View your remotes:
git remote -v
origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

# Add a remote:
git remote add origin https://github.com/user/repo.git

What are the three stages of a file in Git?

BeginnerVery Common

Understanding Git's three-stage model is fundamental. Every file in a Git project moves through these states:

Working Directory (Modified): You've edited the file but haven't told Git about it yet. Git sees it as changed but not staged.
Staging Area (Staged / Index): You've run git add. The file is marked to be included in the next commit. Think of it as a "draft commit".
Repository (Committed): You've run git commit. The change is permanently saved in Git's history.

Bash
# 1. Edit a file → Working Directory
echo "hello" >> index.html

# 2. Stage it → Staging Area
git add index.html

# 3. Commit it → Repository
git commit -m "add hello to index"

# Unstage a file (move back to working dir):
git restore --staged index.html

💡Why interviewers ask this: Many beginners don't understand why git add exists. Being able to explain the staging area clearly shows you understand Git's design.

What is a branch in Git and why is it useful?

BeginnerVery Common

A branch is a lightweight, movable pointer to a specific commit. Branches let you work on different things in parallel without affecting the main codebase.

The default branch is called main (previously master). When you create a new branch, you're essentially creating a safe copy to experiment in.

Bash
# Create and switch to a new branch:
git checkout -b feature/login
# OR (modern syntax):
git switch -c feature/login

# List all branches:
git branch           # local only
git branch -a        # local + remote

# Switch between branches:
git switch main

# Delete a branch after merging:
git branch -d feature/login

Common branching strategies: feature branches (one branch per feature), Git Flow (main, develop, feature, release, hotfix), trunk-based development (short-lived branches off main).

What is git clone vs git fork?

Beginner

git clone: A Git command that copies a remote repository to your local machine. You get all files, branches, and history. Your clone is connected to the original via the origin remote.
Fork (GitHub concept): Creates a copy of someone else's repository on GitHub under your own account. You can make changes freely without affecting the original. Used for contributing to open-source projects via pull requests.

Bash
# Clone: copies to your local machine
git clone https://github.com/original/repo.git

# Typical open-source workflow:
# 1. Fork on GitHub (done in browser)
# 2. Clone YOUR fork locally
git clone https://github.com/YOUR-USERNAME/repo.git
# 3. Add the original as "upstream"
git remote add upstream https://github.com/original/repo.git

What is a commit? What makes a good commit message?

Beginner

A commit is a snapshot of your project at a specific point in time. It records what changed, who changed it, and when. Every commit has a unique SHA hash (like a3f8c2d) as its identifier.

What makes a good commit message:

Use the imperative mood: "Add login page" not "Added login page"
Keep the subject line under 50 characters
Explain what and why, not how
Use a body (separated by blank line) for complex changes

Bash
# ❌ Bad commit messages:
git commit -m "fix"
git commit -m "changes"
git commit -m "asdfgh"

# ✅ Good commit messages:
git commit -m "Add user authentication with JWT"
git commit -m "Fix null pointer error in login handler"
git commit -m "Refactor API calls to use async/await"

# Conventional Commits format (popular in teams):
git commit -m "feat: add password reset email flow"
git commit -m "fix: correct redirect after logout"
git commit -m "docs: update README setup instructions"

What is .gitignore and why is it important?

BeginnerCommon

A .gitignore file tells Git which files and folders to intentionally ignore — they won't be tracked, staged, or committed.

Commonly ignored files include:

Dependencies: node_modules/, vendor/
Environment files: .env, .env.local (contain secrets!)
Build outputs: dist/, build/, *.pyc
OS files: .DS_Store (Mac), Thumbs.db (Windows)
Editor settings: .vscode/, .idea/

Bash — .gitignore
# Dependencies
node_modules/

# Environment variables — NEVER commit these
.env
.env.local
.env.production

# Build output
dist/
build/
*.min.js

# OS clutter
.DS_Store
Thumbs.db

# IDE settings
.vscode/
.idea/

⚠️Security warning: Never commit .env files — they often contain API keys, database passwords, and secrets. Once pushed to a public repo, they can be scraped by bots within seconds.

What is a Pull Request (PR) on GitHub?

BeginnerVery Common

A Pull Request (PR) is a GitHub feature (not a Git command) that lets you notify teammates that you've finished a feature branch and want to merge it into the main branch. It creates a formal review process.

You push your branch to GitHub and open a PR
Teammates review the code, leave comments, request changes
You address feedback and push more commits to the same branch
Once approved, the PR is merged into the target branch
The feature branch is typically deleted after merging

💡GitLab equivalent: Merge Request (MR). Bitbucket also uses "Pull Request". The concept is the same across all platforms.

⚡Intermediate QuestionsQ11–Q21

What is the difference between git merge and git rebase?

IntermediateVery Common

Both integrate changes from one branch into another, but they do so differently and produce different histories:

git merge	git rebase
Creates a merge commit joining two branch tips	Moves (replays) commits onto the tip of another branch
Preserves full history — shows when branches diverged	Creates a cleaner, linear history
Non-destructive — original commits unchanged	Rewrites commit history — dangerous on shared branches
Good for shared/public branches	Good for cleaning up local feature branches

Bash
# Merge feature into main (preserves history):
git switch main
git merge feature/login
# Result: creates a merge commit

# Rebase feature onto main (linear history):
git switch feature/login
git rebase main
# Result: feature commits replayed on top of main

⚠️Golden rule of rebasing: Never rebase a branch that others are working on. Rewriting shared history causes major conflicts for your teammates.

What is a merge conflict and how do you resolve one?

IntermediateVery Common

A merge conflict happens when two branches modify the same part of the same file and Git can't automatically decide which version to keep. Git pauses the merge and asks you to resolve it manually.

Bash — Conflict Markers in a File
<<<<<<< HEAD          # your current branch
const title = "RankWeb3";
=======                    # separator
const title = "RankWeb 3.0";
>>>>>>> feature/rebrand  # incoming branch

Steps to resolve:

Open the conflicted file — Git marks conflicts with <<<, ===, >>>
Edit the file to keep what you want (delete the markers)
Stage the resolved file: git add <file>
Complete the merge: git commit

Bash
# See which files have conflicts:
git status
both modified: src/app.js

# After fixing the file manually:
git add src/app.js
git commit -m "resolve merge conflict in app.js"

# Abort a merge if you need to start over:
git merge --abort

What is git stash and when would you use it?

IntermediateCommon

git stash temporarily shelves (stashes) your uncommitted changes so you can switch to another task, then come back and re-apply them later. It's like putting your work in a drawer.

Bash
# You're mid-feature when an urgent bug comes in:
git stash                     # save current work
git stash push -m "wip: login form"  # with a label

# Now fix the urgent bug on main...
git switch main
# ... fix, commit, push ...

# Come back and restore your work:
git switch feature/login
git stash pop                 # restore + remove from stash
git stash apply               # restore but KEEP in stash

# View all stashes:
git stash list
stash@{0}: On feature/login: wip: login form
stash@{1}: WIP on main: a3f8c2d fix typo

💡Use case: You're working on a feature but your team lead asks for an urgent fix. Stash your WIP, fix the bug, push it, then pop your stash and continue.

What is the difference between git fetch and git pull?

IntermediateVery Common

git fetch: Downloads changes from the remote repository but does NOT merge them into your current branch. Your local files stay untouched. You can review what changed before integrating.
git pull: Does fetch + merge in one step. Downloads changes AND immediately merges them into your current branch.

Bash
# fetch — safe, non-destructive:
git fetch origin
# Remote changes downloaded but NOT applied yet
git log HEAD..origin/main   # see what's new
git merge origin/main        # merge when you're ready

# pull — fetch + merge together:
git pull origin main
# Equivalent to: git fetch + git merge origin/main

# Pull with rebase instead of merge:
git pull --rebase origin main

💡Best practice: Use git fetch + review + git merge on important branches. Use git pull for quick daily syncs on your own feature branches.

What is git reset and what are its three modes?

IntermediateVery Common

git reset moves the current branch pointer (HEAD) back to a previous commit. The three modes control what happens to your working directory and staging area:

Bash
# --soft: move HEAD back, keep changes staged
git reset --soft HEAD~1
# Files are still staged — just undo the commit

# --mixed (default): move HEAD back, unstage changes
git reset HEAD~1
# Files modified in working dir but NOT staged

# --hard: move HEAD back, DELETE all changes
git reset --hard HEAD~1
# ⚠️  DESTRUCTIVE — changes are gone forever

# Reset to a specific commit:
git reset --hard a3f8c2d

⚠️Warning: Never use git reset --hard on commits that have already been pushed to a shared remote. Use git revert instead to safely undo public commits.

What is git revert and how is it different from git reset?

Intermediate

git revert: Creates a new commit that undoes the changes of a previous commit. The original commit stays in history. Safe to use on shared/public branches.
git reset: Moves the branch pointer backwards, effectively removing commits from history. Rewrites history. Dangerous on shared branches.

Bash
# Revert a specific commit (safe for public branches):
git revert a3f8c2d
# Creates new commit: "Revert 'add broken feature'"
# Original commit still in history

# Revert the last commit:
git revert HEAD

# Revert without auto-committing (edit first):
git revert --no-commit HEAD

💡Rule of thumb: If the bad commit is on main or has been pushed — use revert. If it's only in your local unpushed history — reset is fine.

What is git cherry-pick?

Intermediate

git cherry-pick applies the changes from a specific commit onto your current branch — without merging the entire branch. It "picks" only what you need.

Bash
# Apply one specific commit to current branch:
git cherry-pick a3f8c2d

# Cherry-pick a range of commits:
git cherry-pick a3f8c2d..e9b1a4f

# Cherry-pick without committing (review first):
git cherry-pick --no-commit a3f8c2d

Common use case: A critical bug fix was committed to a feature branch. You need that fix on main immediately, but the full feature isn't ready to merge. Cherry-pick grabs just the fix commit.

What are Git tags and how are they different from branches?

Intermediate

Tags are permanent markers pointing to a specific commit — typically used to mark release versions like v1.0.0, v2.3.1. Unlike branches, tags do not move forward as new commits are added.

Bash
# Lightweight tag (just a pointer):
git tag v1.0.0

# Annotated tag (recommended — includes message + metadata):
git tag -a v1.0.0 -m "Release version 1.0.0"

# Tag a specific past commit:
git tag -a v0.9.0 a3f8c2d -m "Beta release"

# Push tags to remote (not pushed by default):
git push origin --tags

# List all tags:
git tag

Branch	Tag
Moves forward with each new commit	Fixed — never moves
Temporary — deleted after merging	Permanent release marker
For ongoing work	For versioned releases

What is git log and how do you use it effectively?

Intermediate

git log shows the commit history. With the right flags it becomes a powerful investigative tool for understanding what changed, when, and by whom.

Bash
# Basic history:
git log

# Compact one-line view:
git log --oneline
a3f8c2d Add login page
b2e1d9a Fix null pointer in handler

# Visual branch graph:
git log --oneline --graph --all --decorate

# Filter by author:
git log --author="Meraj"

# Filter by date:
git log --since="2026-01-01" --until="2026-03-01"

# Search commit messages:
git log --grep="login"

# Show what changed in each commit:
git log -p

What is GitHub Actions?

IntermediateCommon

GitHub Actions is GitHub's built-in CI/CD (Continuous Integration / Continuous Deployment) platform. It lets you automate workflows triggered by events in your repository — like pushing code, opening a PR, or creating a release.

CI: Automatically run tests every time code is pushed
CD: Automatically deploy to production when merged to main
Automation: Auto-label issues, send notifications, generate changelogs

YAML — .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

What is the difference between git diff and git status?

Intermediate

git status: Shows which files have changed — a summary. Tells you if files are untracked, modified, or staged.
git diff: Shows the exact line-by-line changes inside files.

Bash
# What files changed (summary):
git status

# What lines changed in unstaged files:
git diff

# What lines changed in STAGED files:
git diff --staged

# Diff between two branches:
git diff main..feature/login

# Diff between two commits:
git diff a3f8c2d b2e1d9a

# Diff showing only filenames (not lines):
git diff --name-only

🔥Advanced QuestionsQ22–Q30

What is interactive rebase and what can you do with it?

AdvancedCommon

Interactive rebase (git rebase -i) lets you rewrite your local commit history before sharing it. You can squash multiple commits into one, reorder commits, edit commit messages, or drop commits entirely.

Bash
# Interactively rebase last 4 commits:
git rebase -i HEAD~4

# Opens editor with options for each commit:
pick a3f8c2d Add login form
pick b2e1d9a Fix typo in login form
pick c4d3e1f Add form validation
pick d5f2g0h WIP: cleanup

# Change 'pick' to:
# squash (s) — combine with previous commit
# reword (r) — edit the commit message
# edit  (e) — pause to amend the commit
# drop  (d) — delete the commit entirely
# fixup (f) — squash but discard the message

💡Best practice: Clean up messy WIP commits with interactive rebase before opening a pull request. Reviewers will appreciate a logical, readable commit history.

What is git bisect and when would you use it?

Advanced

git bisect helps you find the exact commit that introduced a bug by using a binary search through your commit history. You tell Git which commit was good and which is bad, and it checks out commits in the middle until it pinpoints the culprit.

Bash
# Start bisecting:
git bisect start

# Mark current state as bad (bug exists here):
git bisect bad

# Mark a known-good commit (bug didn't exist here):
git bisect good v1.2.0

# Git checks out a middle commit — test it, then:
git bisect good   # if this commit works fine
git bisect bad    # if this commit has the bug

# Git narrows down... eventually:
a3f8c2d is the first bad commit

# End the session:
git bisect reset

If you have 1,000 commits to check, bisect finds the bad one in just ~10 steps (log₂ 1000 ≈ 10).

What is git reflog and how can it save you?

Advanced

git reflog records every movement of HEAD — including resets, rebases, and branch switches. It's Git's safety net. Even if you delete a branch or do a hard reset, reflog lets you find and recover lost commits.

Bash
# View HEAD history (last 90 days by default):
git reflog
a3f8c2d HEAD@{0}: commit: Add login page
b2e1d9a HEAD@{1}: reset: moving to HEAD~1
c4d3e1f HEAD@{2}: checkout: moving to main

# Scenario: You did git reset --hard and lost commits!
git reflog              # find the lost commit SHA
git checkout c4d3e1f    # go back to it
git checkout -b recovery-branch  # save it as a branch

💡Pro tip: Before running any destructive Git command (hard reset, force push, rebase), always note your current commit SHA from git log. If anything goes wrong, reflog will get you back.

What is a Git submodule?

Advanced

A Git submodule is a repository embedded inside another repository. It lets you include an external project (like a shared library) as a dependency at a fixed commit, while keeping its history separate.

Bash
# Add a submodule:
git submodule add https://github.com/user/lib.git libs/shared

# Clone a repo WITH its submodules:
git clone --recurse-submodules https://github.com/user/main.git

# If you forgot --recurse-submodules:
git submodule update --init --recursive

# Update all submodules to their latest commit:
git submodule update --remote

Submodules are powerful but complex. Many teams prefer package managers (npm, pip) for dependency management, reserving submodules for cases where you need to track a specific commit of an internal shared library.

What is Git Flow and when would you use it?

AdvancedCommon

Git Flow is a branching strategy for managing releases. It defines a strict branching model with specific roles for each branch:

main — production-ready code only. Every commit here is a release.
develop — integration branch. Features merge here first.
feature/* — one branch per new feature. Branches off develop.
release/* — preparation for a new release. Bug fixes only.
hotfix/* — emergency fixes applied directly to main.

Bash
# Start a feature:
git checkout -b feature/user-auth develop

# Finish a feature (merge to develop):
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# Start a release:
git checkout -b release/1.2.0 develop

# Hotfix on main:
git checkout -b hotfix/critical-bug main

💡When to use it: Git Flow suits projects with scheduled releases (e.g., monthly). For continuous deployment (deploy multiple times a day), trunk-based development is simpler and more effective.

What is a force push and why is it dangerous?

Advanced

A force push (git push --force) overwrites the remote branch history with your local history. It is dangerous because it permanently destroys commits on the remote that teammates may have based their work on.

Bash
# ❌ Dangerous — overwrites remote entirely:
git push --force origin main

# ✅ Safer — only force pushes if nobody else pushed:
git push --force-with-lease origin main
# Aborts if remote has commits your local doesn't know about

Only use force push on your own private feature branches after an interactive rebase
Never force push to main, develop, or any shared branch
Always prefer --force-with-lease over --force
Many teams protect main branches on GitHub to prevent force pushes entirely

What is git blame and when is it useful?

Advanced

git blame shows you who last modified each line of a file and in which commit. Despite the name, it's not about blame — it's about understanding context: who wrote this code, when, and why.

Bash
# Show who changed each line:
git blame src/app.js
a3f8c2d (Meraj  2026-02-10 14:22) const PORT = 3000;
b2e1d9a (Sara   2026-01-05 09:11) app.listen(PORT);

# Blame specific lines only:
git blame -L 10,25 src/app.js

# Ignore whitespace changes:
git blame -w src/app.js

Use cases: Investigating when a bug was introduced. Understanding why a specific implementation decision was made (pair with git show <commit> to read the full context). Finding who to ask about a piece of code.

How do you squash commits and why would you?

AdvancedCommon

Squashing combines multiple commits into a single commit. This cleans up messy WIP commit history before merging a feature branch into main — making the project history easier to read and navigate.

Bash
# Method 1: Interactive rebase (most control):
git rebase -i HEAD~3
# Change 'pick' to 'squash' on commits 2 and 3

# Method 2: Merge squash (squash entire branch at once):
git switch main
git merge --squash feature/login
git commit -m "feat: add complete login flow"

# Before squash — messy history:
d Add form validation
c Fix typo
b WIP more login stuff
a Start login form

# After squash — clean single commit:
x feat: add complete login flow

💡GitHub tip: GitHub's "Squash and merge" button on a PR does this automatically — squashes all PR commits into one before merging to main. Many teams use this as their default merge strategy.

How do you set up SSH authentication for GitHub and why is it preferred over HTTPS?

Advanced

SSH (Secure Shell) authentication uses a key pair (public + private) instead of username/password. Once set up, you never type credentials again. It's faster, more secure, and required on many enterprise setups.

Bash
# Step 1: Generate an SSH key pair:
ssh-keygen -t ed25519 -C "your@email.com"
# Saves to: ~/.ssh/id_ed25519 (private) + id_ed25519.pub (public)

# Step 2: Copy your PUBLIC key:
cat ~/.ssh/id_ed25519.pub
# Copy the output

# Step 3: Add to GitHub:
# GitHub → Settings → SSH and GPG keys → New SSH key → Paste

# Step 4: Test the connection:
ssh -T git@github.com
Hi Meraj! You've successfully authenticated.

# Step 5: Use SSH URL for cloning:
git clone git@github.com:username/repo.git
# NOT: https://github.com/username/repo.git

# Switch existing repo from HTTPS to SSH:
git remote set-url origin git@github.com:username/repo.git

SSH	HTTPS
No password needed after setup	Requires token/password each push
More secure (key-based auth)	Works through all firewalls
Preferred for daily development	Easier for one-off clones

Up Next: Python Interview Questions

You've covered Git & GitHub. Next in the series is Python — covering data types, OOP, decorators, generators, and more. Coming soon to RankWeb3.

← JavaScript Q&A

Git & GitHub Interview
Questions & Answers

🌱Beginner QuestionsQ1–Q10

⚡Intermediate QuestionsQ11–Q21

🔥Advanced QuestionsQ22–Q30

Up Next: Python Interview Questions

we believe learning is more than just acquiring knowledge

quick link

help center

Get In Touch

Info@rankweb3.com

©2026, Rankweb3. All Rights Reserved

Git & GitHub InterviewQuestions & Answers

🌱Beginner QuestionsQ1–Q10

⚡Intermediate QuestionsQ11–Q21

🔥Advanced QuestionsQ22–Q30

Up Next: Python Interview Questions

we believe learning is more than just acquiring knowledge

quick link

help center

Get In Touch

Info@rankweb3.com

©2026, Rankweb3. All Rights Reserved

Git & GitHub Interview
Questions & Answers