Git Interview Questions and Answers

Each environment is a stage that adds more trust. The same build output moves through all of them.

• Dev: deploys on every merge, so developers can test quickly.
• QA/Test: automated and manual tests run against realistic data.
• UAT/Staging: looks like production. Used for final business sign-off and performance checks.
• Production: real users. Deployed with approval and a safe strategy.

How to keep them separate:

• Use separate AWS accounts (best). At least use separate VPCs, namespaces and IAM roles for each environment.
• Use separate databases and secrets. Never share production data or credentials with lower environments.
• Use the same infrastructure code and pipeline with different variables, so environments stay alike.
• Move the same image tag forward instead of building again. Limit who can approve production.

What they are checking: Whether you understand environment isolation and moving the same build forward.

Daily workflow: git checkout -b feature/x (or git switch -c), git add, git commit, git push, git status, git log --oneline, git diff.

• stash: saves uncommitted changes for later so you can switch branches. git stash pop brings them back.
• fetch: downloads new commits from the remote. It does not change your working branch.
• pull: fetch plus merge (or rebase with --rebase) into your current branch.
• merge: joins two branches. It keeps history and creates a merge commit.
• rebase: replays your commits on top of another branch to give a straight history. Never rebase commits that are already shared.

Other useful commands:

• git cherry-pick copies single commits.
• git reset and git revert undo changes. Revert is safe for shared history.
• git reflog helps you get back lost commits.

git fetch origin
git rebase origin/main

What they are checking: Whether you are comfortable with everyday Git and know when to use merge or rebase.

Git is a distributed version control tool that runs on your machine. GitHub is a hosting service built around Git repositories.

• Git tracks history, branches and merges locally. It needs no server.
• GitHub (like GitLab and Bitbucket) hosts the remote copy of the repo.
• GitHub adds pull requests, code review, issues, Actions CI/CD, access control and a web UI.
• You can use Git without GitHub, but not GitHub without Git.

git init
git remote add origin [email protected]:org/repo.git
git push -u origin main

What they are checking: Whether you separate the tool from the platform.

They are the three places a change moves through: working directory, staging area (index), then the repository.

• Working directory: the files you edit on disk.
• Staging area: the snapshot of what will go into the next commit, filled by git add.
• Repository (.git): the committed history, created by git commit.

git status            # see all three states
git add app.py        # working directory -> staging
git commit -m "Fix login"   # staging -> repository
git diff              # working vs staging
git diff --staged     # staging vs last commit

The staging area lets you commit only part of your work, for example git add -p to pick hunks.

What they are checking: Whether you understand why git add exists.

Merge joins branches with a merge commit that keeps both histories. Rebase replays your commits on top of another branch to give a straight line.

git switch feature && git merge main      # merge main into feature
git switch feature && git rebase main     # replay feature on main

Golden rule: never rebase commits that others already pulled. A common team habit is to rebase your local feature branch to stay current. Then merge it (often squash) through a pull request.

What they are checking: Whether you know the safety rule about rewriting shared history.

git fetch downloads new commits from the remote. It does not change your working files. git pull is fetch followed by a merge (or rebase) into your current branch.

git fetch origin               # update origin/* references only
git log HEAD..origin/main      # inspect what is new
git merge origin/main          # integrate when ready

git pull                       # fetch + merge
git pull --rebase              # fetch + rebase

Fetch is the safe, read-only choice. Use git config --global pull.rebase true if your team wants a linear history.

What they are checking: Whether you know pull is two operations.

Revert creates a new commit that cancels an earlier one. History stays intact. Reset moves the branch pointer back and drops commits from the branch.

git revert a1b2c3d         # safe on shared branches
git reset --hard HEAD~1    # drop last commit and its changes (local only)
git restore file.py        # discard unstaged edits to a file
git restore --staged file.py   # unstage

• Use revert for anything already pushed to a shared branch.
• Use reset only on local, unpushed work.
• If a reset goes wrong, you can usually fix it with git reflog.

What they are checking: Whether you pick the safe option for pushed commits.

git stash saves your uncommitted changes on a stack. It gives you a clean working directory, so you can switch tasks and come back.

git stash push -m "wip login form"
git stash list
git stash pop            # apply the newest and remove it
git stash apply stash@{1}   # apply but keep it
git stash drop stash@{0}
git stash -u             # include untracked files

Typical use: an urgent bug arrives while you are in the middle of a feature. Stash, switch branch, fix the bug, come back and pop. Stashes are local only and easy to forget, so do not use them as storage.

What they are checking: Whether you handle context switching without throwaway commits.

A conflict happens when both branches changed the same lines. Git stops and asks you to choose the final content.

git merge feature          # CONFLICT in app.py
git status                 # lists 'both modified' files
# open the file, find the markers:
# <<<<<<< HEAD
# your version
# =======
# their version
# >>>>>>> feature
# edit to the final result, remove markers
git add app.py
git commit                 # or: git rebase --continue
git merge --abort          # to back out

Tips:

• Pull often to keep conflicts small.
• Use git mergetool or an IDE.
• Run tests after you resolve.
• Talk to the author when you are not sure what they meant.

What they are checking: Whether you have really resolved one and know how to abort.

A tag is a fixed, human-readable name for a commit, usually used to mark releases such as v1.4.0.

git tag v1.0.0                       # lightweight: just a pointer
git tag -a v1.0.0 -m "Release 1.0.0" # annotated: has author, date, message
git push origin v1.0.0               # tags are not pushed by default
git push origin --tags
git tag -d v1.0.0 && git push origin :refs/tags/v1.0.0   # delete

Annotated tags are stored as full objects, can be signed, and are the right choice for releases. CI/CD pipelines commonly trigger release builds from tags following semantic versioning.

What they are checking: Whether you use tags for release management.

git cherry-pick applies the changes of one or more specific commits onto your current branch as new commits.

Git is a distributed version control system. It tracks changes, helps people work together, and lets you go back to any earlier state.

A .gitignore lists patterns of files Git should not track, such as build output, dependencies, logs and secrets.

A clone copies a repository to your machine. A fork copies a repository to your own account on the hosting service. A branch is a separate line of work inside one repository.

Use log for history, diff for differences, show for one commit and blame for per-line authorship.

A pull request asks the team to review a branch and merge it into another, usually main. Review, CI checks and discussion happen there.

HEAD is the pointer to the commit you currently have checked out, normally through a branch name. A detached HEAD means HEAD points straight to a commit, not to a branch.

Use git commit --amend, which replaces the last commit with a new one.

Both work, SSH uses a key pair and HTTPS uses a username with a personal access token or credential helper.

GitFlow uses long-lived branches with strict roles. Trunk-based development keeps everyone adding small changes to one main branch.

All three move the branch pointer to a target commit. They differ in what happens to the index and the working directory.

Hooks are scripts in .git/hooks that Git runs at specific events, so you can enforce rules automatically.

Treat infrastructure like application code.

A submodule links another repository at a fixed commit inside yours. A subtree copies the other repository's content into your history.

git worktree lets you check out several branches at the same time. Each one is in its own directory, and they share one repository.

--force-with-lease overwrites the remote branch only if it still points where you last saw it. So you cannot silently destroy a teammate's new commits.

Neither is always better. A monorepo gives atomic cross-project changes, shared tooling and easy refactors. Many repos give clear ownership, independent releases and simpler access control.

Signing proves the commit really came from the key holder. Author name and email are easy to fake. Platforms show a Verified badge.

Break the loop by making the CI trigger ignore the commit that CI itself makes.

Treat the secret as stolen. Rotate it first, then clean the history, then stop it from happening again.

The commits still exist in someone's clone and in the reflog. Find the last good commit and move the branch back to it.

Use the reflog. It records every place HEAD and branch tips have been, for about 90 days by default.

Revert the bad commit on main so history stays intact. Ship the revert through the normal pipeline. Then fix the problem properly in a new change.

Integrate more often and make Git remember resolutions.

• Merge or rebase main into the branch daily so each conflict is small.
• Break the work into smaller PRs, hide unfinished features behind flags and merge them to main early.
• Enable rerere so Git replays conflict resolutions you already did:

Use git bisect, which binary searches the history, so about 8 steps cover 200 commits.

Usually it is long history, large binaries committed to Git, or both, and there are both client-side and repo-side fixes.

Copy the commit to the correct branch, then remove it from the wrong one, provided it is not pushed.

Use an interactive rebase to squash, reword and reorder commits on your own branch, then force push safely.

Make main protected so the only way in is a reviewed, passing pull request.

Create the hotfix branch from what is in production (the main branch or the release tag), not from develop. Then merge it back everywhere.