Git Interview Questions

What should you focus on for your Git interview?

Which questions should you start with?

Start with merge versus rebase. It was the most asked question, appearing in 7 of 75 interviews. Can you explain how they differ and when you would choose each? Check that your answer explains the choice, not just the command names.

Other common questions covered Git, GitHub, team branching strategies, and merge conflicts. Use these as checks:

• Can you explain what Git is used for and how it differs from GitHub?
• Can you choose a branching strategy for a team and explain your choice?
• Can you describe a merge conflict and walk through how you would resolve it?

Can you explain what everyday commands do?

The command questions cover saving changes, fetching updates, pulling, pushing, stashing, and writing commit messages. Start by comparing git fetch with git pull. Can you also explain where git fetch stores downloaded changes?

Then talk through a change you want to submit for review. Which commands would you use to create a branch and commit your changes? How would you submit them for review and merging? What would you write in the commit message? Separately, check that you can explain what stashing does.

Can you take a feature from a branch to production?

Pull requests and code review were the most common topic in these interviews, appearing in 15 of 75 interviews. The questions go beyond defining a pull request.

• How would you prepare a pull request and review someone else's changes?
• How would you use protected branches and required quality checks?
• How would you move a feature through integration branches, review, and deployment to production?

Also check whether you can explain how release tags, deployment pipelines, and shared environments fit into that workflow.

Can you handle recovery and repository choices?

The questions also cover history, recovery, and repository management. Test whether you can explain concrete actions and choices:

• How do revert and reset differ?
• How would you approach recovery on a shared branch?
• How would you remove a secret from Git history?
• When would you choose a monorepo rather than multiple repositories?
• What are submodules, and how would you use them?

For repository management, also check whether you can explain dependency lock files and how you would manage shared configuration.

Who gets asked Git

The 20 most asked Git questions

Counted by interview, not by mention: a question asked twice in one conversation counts once.

1. How do Git merge and rebase differ, and when would you choose each?

   Asked in 7 of 75 interviews · last asked Oct 13 · Concept · Junior

   Show answer

   Merge combines branch histories without rewriting existing commits. Rebase replays commits on a new base, giving them new IDs and making history more linear. I choose merge for shared branches to preserve history. I choose rebase to update a local feature branch before merging, but avoid rebasing commits others already use.

   • Merge may create a merge commit; a fast-forward merge only moves the branch pointer.
   • Rebase rewrites history, so rebasing shared commits requires coordination.
   • Both can cause conflicts; rebase may require resolving conflicts for several replayed commits.

   What the interviewer checks: The interviewer checks whether you understand history changes and can choose a safe workflow for team collaboration.

   Other ways it was asked

   • “What is the difference between merging and rebasing in Git?”
   • “What is the difference between Git merge and Git rebase, when would you use each, and what should you avoid?”
   • “What is the difference between Git merge and Git rebase?”

2. What is GitHub?

   Asked in 4 of 75 interviews · last asked Aug 27 · Concept · Junior

   Show answer

   GitHub is an online platform for hosting Git repositories and working on code with others. Git tracks changes, while GitHub adds tools for pull requests, code reviews, issue tracking, and automation. It supports both public and private repositories.

   • GitHub is a service built around Git, not Git itself.
   • Pull requests let teams review and discuss changes before merging them.
   • GitHub Actions can automate tasks such as testing and deployment.

   What the interviewer checks: The interviewer is checking whether you can explain GitHub’s purpose and distinguish it from Git.

3. What is Git, and what is it used for?

   Asked in 4 of 75 interviews · last asked Oct 3 · Concept · Junior

   Show answer

   Git is a distributed version control system. It tracks changes to files, mainly source code, so you can review history and restore earlier versions. It helps people work on the same project by keeping work on separate branches and combining changes.

   • Local repositories keep project history, so most work does not need a network connection.
   • Commits record changes, making them easier to review or undo.
   • Branches separate work; merging combines changes and may require resolving conflicts.
   • Git is the tool; GitHub is a service that hosts Git repositories.

   What the interviewer checks: The interviewer is checking whether you understand version control and how Git supports teamwork.

   Other ways it was asked

   • “What is Git?”
   • “What is Git used for, and what problems does it solve?”

4. What Git branching strategy would you choose for a team, and why?

   Asked in 4 of 75 interviews · last asked Sep 15 · Tooling · Mid-level

   Show answer

   I would usually choose a simple workflow with short-lived feature branches and a main branch that stays ready to release. Developers merge through pull requests after review and automated checks. This supports frequent integration during Agile sprints and reduces merge conflicts. I would add release branches if the team must support multiple released versions.

   • Choose based on release frequency, team needs, and supported versions.
   • Keep feature branches small and merge often; do not wait until the sprint ends.
   • Protect main with required reviews and automated checks.
   • Use feature flags to merge unfinished work without exposing it to users.

   What the interviewer checks: The interviewer wants to see whether you can choose a practical workflow and explain its trade-offs.

   Other ways it was asked

   • “What is your go-to approach for setting up a branching strategy for a project, particularly when developing in Agile sprints?”
   • “When working with Git and GitHub, how do you typically structure branches for a team working on features?”
   • “What branching strategy do you follow?”

5. What is a merge conflict in Git, and how do you resolve it?

   Asked in 4 of 75 interviews · last asked Sep 15 · Concept · Junior

   Show answer

   A merge conflict happens when Git cannot automatically combine changes. I use `git status` to find conflicting files, then edit them to keep the correct content and remove conflict markers. I check the result, run tests, and stage resolved files with `git add`. Then I finish the merge with `git commit`, or continue a rebase with `git rebase --continue`.

   • Conflicts often involve overlapping edits, but can also involve deleted or renamed files.
   • Resolve the intended result, rather than blindly keeping one side.
   • Staging marks a file as resolved; it does not prove the result is correct.
   • After resolving all conflicts, finish the merge or continue the operation that stopped.

   What the interviewer checks: The interviewer checks whether you can explain conflicts and safely complete the operation after resolving them.

   Other ways it was asked

   • “What is a merge conflict?”
   • “What is a merge conflict, and what should you do after resolving one?”
   • “How would you resolve a merge conflict in Git?”

6. What is the difference between git fetch and git pull?

   Asked in 3 of 75 interviews · last asked Aug 25 · Concept · Junior

   Show answer

   `git fetch` downloads new data from a remote and updates remote-tracking branches without changing your current branch or working files. `git pull` runs fetch, then integrates the fetched branch into your current branch. Depending on options and settings, pull can merge, rebase, or require a fast-forward.

   • Fetch lets you review remote changes before integrating them.
   • Pull can change your working files and may cause conflicts during merging or rebasing.
   • A fast-forward-only pull fails if the branches have diverged.

   What the interviewer checks: The interviewer is checking whether you understand downloading changes versus integrating them into your current branch.

   Other ways it was asked

   • “What is the difference between Git fetch and Git pull?”
   • “What is the difference between git pull and git fetch?”

7. What are pull requests and merge requests, and how do they support code review?

   Asked in 3 of 75 interviews · last asked Sep 28 · Concept · Junior

   Show answer

   Pull requests and merge requests are proposals to merge changes from one branch into another. GitHub calls them pull requests; GitLab calls them merge requests. They let teammates review changes, discuss problems, request updates, and approve the work before merging.

   • They are hosting platform features, not Git commands.
   • Reviewers can comment on specific lines and check the full set of changes.
   • Automated checks can run, and branch rules can require checks and approvals before merging.
   • Opening a request does not merge the changes.

   What the interviewer checks: The interviewer is checking whether you understand how teams review and approve changes before merging them.

   Other ways it was asked

   • “What is a pull request in GitHub, and what is it used for?”
   • “What is a pull request?”
   • “How do merge requests and pull requests support code review and collaboration?”

8. What does git fetch do, and where does it store downloaded changes?

   Asked in 2 of 75 interviews · last asked Sep 4 · Concept · Mid-level

   Show answer

   git fetch downloads commits and other Git objects from a remote into your local repository, normally in .git/objects. It updates remote-tracking branches such as origin/main and records fetched references in .git/FETCH_HEAD. It does not merge changes into your current branch or change your working files.

   • Downloaded objects stay in Git’s internal storage, not your working files.
   • Remote-tracking branches are updated according to the fetch configuration or command options.
   • FETCH_HEAD records fetched references; it does not contain the downloaded file contents.
   • Use merge or rebase separately to bring fetched changes into your branch.

   What the interviewer checks: The interviewer checks whether you understand where fetched data goes and how fetching differs from integrating changes.

   Other ways it was asked

   • “Where does Git fetch store the changes it downloads?”
   • “What will happen if you do git fetch?”

9. Which Git commands create a branch, commit changes, and submit them for review and merging?

   Asked in 2 of 75 interviews · last asked Oct 21 · Tooling · Mid-level

   Show answer

   Use `git switch -c` to create a branch, `git add` to stage changes, and `git commit` to save them. Use `git push -u origin` with the branch name to upload it. Then open a pull request for review and merging through the hosting website or a tool such as GitHub CLI.

   • Start the feature branch from the intended base branch, usually main.
   • `git commit` without options or paths includes only staged changes.
   • Pushing a branch does not create a pull request.
   • A pull request lets reviewers approve changes before they are merged into the target branch.

   CodeCopy

   git switch main
   git switch -c feature-name
   # Edit files, then check your changes.
   git add .
   git commit -m "Add feature"
   git push -u origin feature-name
   # GitHub CLI, not a built-in Git command:
   gh pr create --base main --title "Add feature" --body "Describe the changes."

   What the interviewer checks: The interviewer checks whether you understand the branch, staging, commit, push, and review workflow without committing directly to main.

   Other ways it was asked

   • “Which Git commands do you use when working on a branch and creating a pull request?”
   • “How would you create a branch, commit changes, and integrate them without modifying the main branch directly?”

10. How do you take a feature from its Git branch through review and deployment to production?

    Asked in 2 of 75 interviews · last asked Feb 17 · Scenario · Mid-level

    Show answer

    I create a feature branch from the latest main branch, make focused commits, and open a pull request. I pass automated checks, address review feedback, and merge after approval. Then I deploy the tested build to staging, verify it, and promote that same build to production. I monitor the release and keep a rollback plan ready.

    • Follow the team's branch rules and require review and passing checks before merging.
    • Keep secrets and environment settings outside the build so the same build can move between environments.
    • Use a commit ID or release tag to trace each deployment.
    • Check production health and roll back if the release causes problems.

    What the interviewer checks: The interviewer checks whether you can move code through review, testing, and deployment safely and trace each release.

    Other ways it was asked

    • “How do you manage the Git workflow for a new feature from development through the different environments to production?”
    • “How should a developer create a branch, raise pull requests, and prepare a product for deployment to the next stage?”

11. How do you manage Git branches and merge conflicts in a team workflow?

    Asked in 2 of 75 interviews · last asked Sep 23 · Tooling · Junior

    Show answer

    I use short-lived feature branches and merge through reviewed pull requests, with checks required on the main branch. I regularly bring in changes from the target branch to reduce conflicts. When conflicts happen, I review both changes, agree on the intended result with teammates, edit the files, and test before completing the merge or rebase.

    • Follow the team's branching rules and keep changes small.
    • Resolve conflicts by understanding both changes, not blindly choosing one side.
    • Stage resolved files, then complete the merge or continue the rebase.
    • Avoid rebasing shared branches without agreement because it rewrites commit history.

    What the interviewer checks: The interviewer is checking whether you can coordinate changes safely and resolve conflicts without losing teammates' work.

    Other ways it was asked

    • “How do you use Git branches and resolve merge conflicts?”
    • “Could you walk me through how you typically manage Git workflows for a team-based project? How do you approach branching strategies or handling merge conflicts?”

12. How do you choose between a monorepo and multiple repositories, and what are the trade-offs?

    Asked in 2 of 75 interviews · last asked Oct 19 · Design · Mid-level

    Show answer

    I choose based on how closely the projects work together, who needs access, and how teams build and release them. A monorepo makes shared code and coordinated changes easier, but needs tooling to keep builds fast. Multiple repositories give clearer access boundaries and team independence, but make cross-project changes harder. I would switch when these costs outweigh the benefits.

    • A monorepo can update front end and back end together, but does not require deploying them together.
    • Multiple repositories support separate access rules, but shared code needs versioning and dependency updates.
    • Testing only affected projects can keep CI fast in large monorepos.
    • Switch based on repeated coordination, build, or access problems—not team size alone.

    What the interviewer checks: The interviewer checks whether you can weigh coordination, access control, tooling, and release needs rather than favoring one layout.

    Other ways it was asked

    • “What are the key advantages and challenges of using a monorepo for managing both the front end and back end?”
    • “How do you choose between a monorepo and a multirepo, and what criteria would lead you to switch from one to the other?”

13. How would you use Git in business analysis work?

    Asked in 2 of 75 interviews · last asked Sep 28 · Tooling

    Show answer

    I would use Git to track changes to requirements, process diagrams, and analysis scripts. I would make small commits with clear messages and use branches and pull requests to review changes with the team. This keeps a shared history of what changed and why.

    • Text files, such as Markdown and SQL, are easy to compare and review.
    • Link commits or pull requests to work items for traceability.
    • Git can store binary documents, but comparing and merging them is harder.
    • Keep passwords and sensitive business data out of the repository.

    What the interviewer checks: The interviewer is checking whether you can use Git to manage analysis work and collaborate with others.

    Other ways it was asked

    • “How do you use Git in your day to day?”
    • “How have you used Git in your work?”

14. What is the difference between Git and GitHub?

    Asked once · last asked Aug 20 · Concept · Junior

    Show answer

    Git is a version control tool that tracks changes in files. GitHub is an online service that hosts Git repositories and adds tools for teamwork, such as pull requests and issues. You can use Git locally without GitHub or an internet connection.

    • Git manages commits, branches, and merges.
    • GitHub hosts repositories and supports code review and collaboration.
    • Git works without GitHub; other services can also host Git repositories.

    What the interviewer checks: The interviewer is checking whether you can separate the version control tool from the hosting service.

15. How do you manage code versions and changes in a software project?

    Asked once · last asked Mar 18 · Tooling · Junior

    Show answer

    I use Git to track changes, with a separate branch for each task. I make small, clear commits and use pull requests for review and automated tests before merging. I tag releases and use revert commits to undo changes safely on shared branches.

    • Keep commits focused and write messages that explain the change.
    • Review changes and run tests before merging into the main branch.
    • Resolve merge conflicts carefully and test the result.
    • Use tags to mark releases; avoid rewriting shared history.

    What the interviewer checks: The interviewer is checking whether you can track changes, work with a team, and undo mistakes safely.

16. What is the Azure equivalent of GitHub?

    Asked once · last asked Mar 20 · Concept · Junior

    Show answer

    Azure DevOps is Microsoft's closest equivalent to GitHub. Within Azure DevOps, Azure Repos hosts Git repositories and supports pull requests and code reviews. Azure Pipelines handles automated builds and deployments, similar to GitHub Actions.

    • Azure Repos is the direct match for GitHub's Git repository hosting.
    • Azure DevOps also includes tools for work tracking, testing, and package hosting.
    • GitHub and Azure DevOps are separate products, both owned by Microsoft.

    What the interviewer checks: The interviewer is checking whether you can distinguish Azure DevOps from its repository service, Azure Repos.

17. What is version control?

    Asked once · last asked Mar 27 · Concept · Junior

    Show answer

    Version control is a system that tracks changes to files over time. It lets you review past changes, restore earlier versions, and work with others without losing track of their changes. Git is one example of a version control system.

    • Keeps a history of saved changes, including who made them and when.
    • Helps people combine their work and resolve conflicting changes.
    • Supports branches so work can happen separately before being combined.

    What the interviewer checks: The interviewer is checking whether you understand why version control is useful for tracking changes and working together.

18. What is a Git repository, and how does it support version control?

    Asked once · last asked Aug 5 · Concept · Junior

    Show answer

    A Git repository stores a project's files and their recorded history. Git saves changes as commits, so you can compare versions, track who made changes, and restore earlier work. Branches let people work separately and merge their changes later. Each full clone has the project history, so most work can happen offline.

    • Commits record snapshots of tracked files, with an author, message, and links to earlier commits.
    • Branches keep separate lines of work; merging brings changes together.
    • Remote repositories let people share commits and work together.
    • Local history supports offline comparisons, commits, and recovery of earlier versions.

    What the interviewer checks: The interviewer checks whether you understand how Git stores history and supports safe changes and teamwork.

19. Name a few Git repository hosting services.

    Asked once · last asked Aug 20 · Concept · Junior

    Show answer

    GitHub, GitLab, Bitbucket, and Azure Repos are Git repository hosting services. They store remote repositories and help teams share code, review changes, and manage access.

    • Git is the version control tool; these services host Git repositories.
    • These services support private repositories and team collaboration.

    What the interviewer checks: The interviewer is checking whether you know common hosting services and understand how they differ from Git itself.

20. What is a local repository in Git?

    Asked once · last asked Aug 20 · Concept · Junior

    Show answer

    A local repository is a Git repository stored on your computer. It keeps commit history and branches, usually in a .git folder. You can commit changes and view history without an internet connection. You use push and fetch to exchange commits with a remote repository.

    • Local commits stay on your computer until you share them.
    • The working directory holds files you edit; the repository stores their committed history.
    • A local repository can exist without a remote repository.

    What the interviewer checks: The interviewer is checking whether you understand where Git stores history and how local work differs from remote sharing.

Related interview questions

• Software Engineer interview questions
• DevOps Engineer interview questions
• QA Engineer interview questions
• Data Engineer interview questions
• Cloud Engineer interview questions
• Data Structures and Algorithms interview questions
• OOP and Design Patterns interview questions
• System Design interview questions
• Microservices interview questions
• REST API interview questions
• Kafka and Message Queues interview questions
• Caching and Redis interview questions
• Operating Systems interview questions
• Computer Networks interview questions

How this list is made

Every question here was asked by a real interviewer in a real job interview that a candidate ran MeetAssist in. After the call, the interviewer's questions are pulled from the transcript. Practice sessions, tests, exams and anything that was not a job interview are dropped.

Questions are rewritten so they make sense on their own: names of people, employers and clients are removed, and speech-to-text mistakes are fixed. Small talk, logistics and questions about one candidate's own résumé are left out. Rephrasings of the same question are merged, and the count is the number of different interviews it came up in.

The interviews come from candidates who use MeetAssist, so they lean towards software, data and AI roles: the shares describe these interviews, not every Git interview. Answers to the most asked questions are written and checked by an editor; a "common mistake" is shown only when reviews of real answers in these interviews show it, with the count.

75 interviews, 63 candidates, Nov 2025 to Oct 2026. Updated every month with new interviews.