Git and GitHub Interview Questions for Freshers (2026): The One Resume Claim They Can Check Before Meeting You
Updated August 2026
Git sits on almost every fresher resume, and it is one of the very few claims on that page an interviewer can verify in thirty seconds without asking you anything. Your GitHub profile is public. A profile with three repositories, each containing a single commit called "final" made on the day before the deadline, tells a reviewer something specific — not that you are dishonest, but that you have used Git as an upload tool rather than as version control. That impression is formed before you speak, which is why this page covers the profile as well as the questions.
At fresher level the questions themselves are usually shallow: what Git is, what a commit is, how Git differs from GitHub. Candidates prepare those and then lose the round on one practical follow-up — "you and a teammate edited the same file, what happens and what do you do?" — because they have only ever worked alone in their own repository, where conflicts never occur. The definitions are the easy half. The scenarios are where the marks are.
If you have only ever worked solo, that is fixable in about a week and is the highest-value preparation on this page. Take one repository with a friend or a project partner, both edit the same file deliberately, and resolve the conflict properly. Open a pull request and have them review it, then review one of theirs. Break something and recover it — amend a commit, undo a staged change, revert something you already pushed. Doing each of these once means you are describing your own experience in the interview rather than reciting an answer, and interviewers can hear the difference immediately.
Frequently asked questions
What is Git, and how is it different from GitHub?
Git is a distributed version control system that runs on your machine and tracks changes to files over time — it works entirely offline and needs no account or server. GitHub is a hosting service for Git repositories that adds collaboration features on top: pull requests, code review, issues, actions, access control. Distributed means every clone is a full repository with the complete history, not a checkout from a central server, which is why you can commit, branch and view history with no network connection. Alternatives to GitHub include GitLab and Bitbucket, and mentioning that shows you understand the distinction rather than treating the two words as synonyms.
What is a commit, and what makes a good commit message?
A commit is a snapshot of your repository at a point in time, identified by a hash, carrying an author, a timestamp, a message and a pointer to its parent commit. A good message has a short imperative summary line — "Add validation to the signup form" rather than "added stuff" or "changes" — and, where the change is not self-explanatory, a body saying why rather than what, since the diff already shows what. Interviewers ask this because commit messages are visible in your public history, so the answer you give will be checked against your profile whether or not anyone says so.
What is the difference between git fetch and git pull?
git fetch downloads new commits and updates your remote-tracking branches, but does not change your working directory or your current branch — it lets you see what has changed before deciding what to do. git pull is git fetch followed immediately by a merge (or a rebase, with the appropriate configuration) into your current branch. The practical implication is that fetch is always safe, while pull can produce a merge commit or a conflict you were not ready for. Fetching first and looking at the incoming changes is a habit worth having, and worth mentioning.
Merge versus rebase — what is the difference and when do you use each?
Merging combines two branches by creating a new merge commit that has both branch tips as parents, preserving the true shape of history including the fact that work happened in parallel. Rebasing replays your commits on top of another branch as if you had started from there, producing a linear history but rewriting your commits with new hashes. The rule interviewers want to hear is that you never rebase commits that have been pushed and that others may have based work on, because rewriting shared history forces everyone else into a painful recovery. Rebase locally to tidy your own branch before opening a pull request; merge when integrating shared branches.
What is a merge conflict and how do you resolve one?
A conflict occurs when two branches change the same lines of the same file, or when one deletes a file the other modified, and Git cannot determine which version is correct. Git marks the file with conflict markers separating your version from the incoming one, and pauses the merge. To resolve: open each conflicted file, decide what the correct final content is — often a combination rather than one side wholesale — remove the markers entirely, then stage the resolved files and complete the merge or continue the rebase. Two things impress an interviewer here: saying that you talk to whoever wrote the other change rather than silently discarding it, and knowing that you can abort the whole thing and start again if it becomes confusing.
What is a branch, and what branching workflow have you used?
A branch is a movable pointer to a commit, which makes creating one nearly free — that is why branching is routine in Git rather than an event. Describe an actual workflow: a main branch that always stays working, a separate branch for each feature or fix created from main, work committed there, then a pull request back into main after review. Mention keeping your branch updated with main while you work, so the eventual integration is small. If your project experience was genuinely solo and single-branch, say so honestly and describe the workflow you have read about and are practising — that lands far better than inventing team experience which the follow-up question will unravel.
What is the staging area, and why does it exist?
The staging area, or index, is an intermediate space between your working directory and your repository, where you assemble exactly what the next commit will contain. It exists so a commit can be a deliberate, coherent unit rather than a dump of everything you happen to have changed — if you fixed a bug and also adjusted some formatting, you can stage and commit them separately. The three-stage model is worth stating plainly: working directory, staging area, repository, with add moving changes into staging and commit moving staged changes into history.
How do you undo changes at each stage?
This is the most useful practical question in the set. For an unstaged change in your working directory, restore the file from the last commit. For a change already staged, unstage it first, which leaves the edit intact in your working directory. For the most recent commit that has not been pushed, amend it to fix the message or include a forgotten file, or reset back one commit — soft keeps the changes staged, mixed keeps them in the working directory, hard discards them entirely and is the one that loses work. For a commit that has already been pushed, create a revert commit that undoes it rather than rewriting history. Knowing which of these destroys work and which does not is the actual content of the question.
What is the difference between git reset and git revert?
Reset moves the branch pointer backwards, effectively removing commits from that branch history — it rewrites history and is therefore safe only on commits you have not shared. Revert creates a new commit that applies the inverse of a previous commit, leaving the original in place, which is safe on shared branches because it adds to history rather than rewriting it. The one-line version for an interview: use revert on anything already pushed, and reset only on local work. Add that reset --hard is the command that actually discards changes, and is the one to be careful with.
What is HEAD, and what does detached HEAD mean?
HEAD is a pointer to your current position — normally to the branch you have checked out, which in turn points to its latest commit. Detached HEAD means HEAD points directly at a commit rather than at a branch, which happens when you check out a specific commit hash or a tag. You can look around and even commit in that state, but those commits belong to no branch and will be difficult to find once you check out something else. The recovery is to create a branch at that point before leaving, and knowing that is what the question is really testing.
What is .gitignore, and what belongs in it?
A file listing patterns Git should not track. It belongs to the repository and is itself committed, so the whole team shares it. Typical contents: dependency directories such as node_modules, build and dist output, editor and OS files, local logs, and — most importantly — anything holding credentials, such as .env files or key files. The distinction worth stating is that .gitignore only prevents untracked files from being added; a file already tracked keeps being tracked regardless of what you add to the ignore list, which is exactly the trap behind the next question.
You accidentally committed an API key. What do you do?
Treat the key as compromised immediately and rotate it — revoke it at the provider and issue a new one. That is the first step and the one candidates miss, because removing it from the repository does not un-share it: anyone may have cloned or seen it, and on a public repository automated scrapers find keys within minutes. Then remove it from the codebase, add the file to .gitignore, and if the commit was never pushed, amend or reset it away. If it was pushed, the history needs rewriting with a history-rewriting tool, which requires coordination with everyone who has cloned the repository — and even then, rotation remains the step that actually protects you. An interviewer asking this is testing security instinct more than Git mechanics.
What is a pull request, and what happens in code review?
A pull request is a request to merge one branch into another, hosted on the platform rather than being a Git feature itself, which opens a space for discussion and review before the merge. Reviewers read the diff, leave comments on specific lines, ask questions and request changes; the author pushes further commits to the same branch, which update the pull request automatically. Useful things to add: keeping a pull request small enough to review properly, writing a description that explains the intent rather than restating the diff, and responding to review comments rather than silently force-pushing over them. Having actually opened and received a review on one is worth more than any definition.
What does git stash do, and when would you use it?
Stash takes your uncommitted changes, saves them on a stack and reverts your working directory to a clean state, so you can switch context without committing half-finished work. The typical use is a colleague asking you to check something on another branch while you are mid-change. You reapply the changes afterwards — either popping them off the stack or applying them while keeping the entry. Worth mentioning that stashes are local and easily forgotten, so treating a stash as long-term storage is a good way to lose work.
What are origin, remote, and upstream — and what is the difference between forking and cloning?
A remote is a named reference to another copy of the repository; origin is simply the conventional name for the one you cloned from. In an open-source workflow, upstream is the conventional name for the original project when you are working from your own fork. Cloning downloads a repository to your machine and keeps origin pointing at that same repository. Forking creates your own server-side copy on the platform, which you then clone — so your origin is your fork, and you add the original as upstream to pull in changes. You fork when you do not have write access to the original, which is exactly the open-source contribution case.
How would you contribute to an open-source project?
Fork the repository, clone your fork, add the original as upstream, and create a branch for your change. Before writing anything, read the contributing guidelines and look for an existing issue — many projects want a discussion before a pull request, and unsolicited large changes are frequently declined regardless of quality. Make a focused change, commit it with a clear message, push to your fork and open a pull request against the original, describing what it does and why. Then expect review comments and respond to them. Starting small — documentation, a failing test, a well-scoped bug — is genuinely how most first contributions land, and describing that path shows you know how the process works rather than only the commands.
What does git cherry-pick do?
It applies the change introduced by a specific commit onto your current branch, creating a new commit with a new hash. It is useful when a fix made on one branch is needed on another without merging everything else along with it — a hotfix on a development branch that must also reach a release branch, for example. The caution worth mentioning is that repeated cherry-picking between long-lived branches creates duplicate commits with different hashes representing the same change, which makes later merges confusing.
What is a tag, and how does it differ from a branch?
Both point at a commit, but a branch moves forward as you commit while a tag stays fixed — it marks a specific point permanently, which is why tags are used to mark releases. Lightweight tags are just a pointer; annotated tags are stored as full objects with a tagger, date and message, which is what release tags normally use. A detail worth knowing: tags are not pushed automatically along with commits, so they have to be pushed explicitly, and forgetting that is a common source of confusion.
What does squashing commits do, and why would you do it?
Squashing combines several commits into one, usually via interactive rebase or the squash-merge option on a pull request. The reason is readability: fifteen commits reading "fix", "fix again", "typo" describe your afternoon rather than the change, and a single coherent commit is easier for anyone reading history later — including you. The trade-off is that you lose the granular steps, which occasionally matter for bisecting a bug. Many teams squash on merge for exactly this reason, and knowing why they do it is more useful than the mechanics of the rebase.
How do you find out who changed a line, and when?
Blame annotates each line of a file with the commit, author and date that last modified it, which is how you find the context behind code that puzzles you. Log shows commit history and can be filtered by file, author, date range or message content, and shows the changes for a specific file over time. Worth saying explicitly in an interview: the purpose is understanding why a change was made — usually so you can ask the person who made it — rather than assigning blame, and framing it that way reads well.
Tell me about your GitHub profile.
Answer this as though the interviewer has already opened it, because they may well have. Talk about one or two repositories you can discuss in depth — what the project does, a specific technical decision you made and why, something that went wrong and how you fixed it — rather than listing everything you have pushed. If your history is thin or the commits are bulk uploads from a semester of solo work, say so plainly and describe what you are doing about it now; that is a far better answer than pretending. Interviewers are not expecting an impressive open-source record from a fresher. They are checking whether you have actually built something and can talk about it honestly.
Don't just read Git & GitHub questions — get asked them
Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.
Start a free AI mock interviewHow to prepare
- Open your own GitHub profile and read it as a stranger before you apply anywhere. Pin the two or three repositories you can discuss confidently, make sure each has a README explaining what it does and how to run it, and remove or archive dead experiments. This is roughly twenty minutes of work on something a recruiter can see before deciding whether to talk to you.
- Create a merge conflict on purpose this week and resolve it. Two branches, same file, same lines, then work through the markers, stage the result and complete the merge. Every fresher who has only worked alone loses marks on this question, and one afternoon removes the problem permanently.
- Learn the undo commands properly, and know which of them destroy work. Restoring a file, unstaging, amending, the three reset modes and revert cover essentially every situation a fresher will be asked about, and the practical question is usually phrased as a mistake you need to fix.
- Never commit a .env file or a key, and know the answer if you already have: rotate the credential first, then clean the repository. On a public repository, automated scanners find committed keys within minutes, so removing the file without rotating leaves you exposed while feeling fixed.
- Write commit messages you would be comfortable having read aloud in the interview, because your history is public. An imperative summary line describing the change beats "update" or "final final" — and this is one of the few habits that improves your profile passively from now on.
- If your project was genuinely solo, say so rather than inventing team experience. "I worked alone, so I have practised branching and conflict resolution deliberately since" is credible and checkable; a fabricated team workflow falls apart on the second follow-up question.
- Practise explaining one project out loud from your own repository — what it does, one decision you made and why, one thing that broke. That answer doubles as your project explanation in the technical round and as material for behavioural questions.
Where these questions get asked
- TCS NQT guide and Infosys hiring guide — the two biggest exams these questions appear in.
- All company placement guides — pattern, syllabus and rounds for every mass recruiter.