3 July, 2026 (Last Updated)

Top 50+ Git Interview Questions for Freshers

Git is one of the most important skills for freshers preparing for software development, web development, DevOps, testing, data engineering, and full-stack roles. It helps developers track code changes, collaborate with teams, manage branches, and work safely on real projects.

According to GitHub’s Octoverse 2025 report, GitHub crossed 180 million developers and 630 million projects, showing how widely Git-based collaboration is used in modern software development.

This article covers practical Git interview questions for freshers with clear answers, examples, and real project-based explanations.

Beginner Git Interview Questions

These Git basic interview questions are useful for freshers who are learning version control for software development, DevOps, automation testing, and full-stack roles.

This section covers the foundation of Git: repositories, commits, branches, staging, remotes, and everyday commands used in real projects.

1. What is Git, and why is it used?

Git is a distributed version control system used to track changes in source code. It helps developers save different versions of their work, collaborate with teammates, and recover previous code when needed.

In a real project, many developers may work on the same codebase. Without Git, it becomes difficult to know who changed what, when the change happened, and how to safely combine everyone’s work.

Git is used for:

• Tracking code history
• Working on branches
• Collaborating with teams
• Reverting mistakes
• Managing releases
• Supporting DevOps workflows

For freshers, Git is important because almost every software team uses it in day-to-day development.

2. What is the difference between Git and GitHub?

Git is a version control tool installed on your system, while GitHub is a cloud-based platform used to host Git repositories online.

Feature	Git	GitHub
Type	Version control system	Hosting platform
Works	Locally	Online
Used for	Tracking changes	Collaboration and sharing
Example	git commit	Pull request

For example, you can use Git on your laptop to create commits. Later, you can push those commits to GitHub so your team can access the code.

3. What is a Git repository?

A Git repository is a project folder that Git tracks. It contains all project files and the complete history of changes made to those files.

A repository can be:

• Local repository: Stored on your computer
• Remote repository: Stored on platforms like GitHub, GitLab, or Bitbucket

When you run:

Git creates a hidden .git folder inside the project. This folder stores metadata, commit history, branches, and configuration.

In simple terms, a repository is not just a folder with files. It is a tracked project where Git remembers every committed change.

4. What is the staging area in Git?

The staging area is an intermediate space between your working directory and your commit history. It allows you to choose which changes should be included in the next commit.

Flow:

For example, after editing three files, you may want to commit only two of them. You can stage only those two files using:

Then commit them.

The staging area gives developers control over commits. Instead of committing all changes blindly, you can create clean and meaningful commits with only related changes.

5. What is a commit in Git?

A commit is a saved snapshot of your project at a specific point in time. It records what changed, who made the change, and when it was made.

A commit usually contains:

• Changed files
• Author details
• Timestamp
• Commit message
• Unique commit ID

Example:

A good commit message should clearly explain the purpose of the change. For example, “Fix login button alignment” is better than “changes done”.

Commits help developers review project history, revert mistakes, and understand how the code evolved over time.

6. What is the use of git init?

The git init command is used to create a new Git repository in an existing folder. When this command is executed, Git creates a hidden .git directory inside the project.

Example:

After running this command, Git starts tracking the project. You can then add files, create commits, and manage history.

Typical flow:

This command is mostly used when starting a new project locally. If you are downloading an existing project from GitHub, you usually use git clone instead of git init.

7. What does git status show?

The git status command shows the current state of the working directory and staging area. It tells you which files are modified, staged, untracked, or ready to commit.

Example:

It can show:

• Files changed but not staged
• Files staged for commit
• New untracked files
• Current branch name
• Whether local branch is ahead or behind remote

For freshers, this is one of the most useful commands because it helps avoid confusion before committing.

A good habit is to run git status before git add, before git commit, and before pushing code to a remote repository.

8. What is the difference between git add and git commit?

git add moves changes to the staging area, while git commit saves those staged changes into Git history.

Command	Purpose
git add	Selects changes for commit
git commit	Saves staged changes permanently

Example:

If you modify a file but do not run git add, Git will not include that change in the next commit.

Think of git add as preparing files and git commit as saving them. This two-step process helps developers create organized commits instead of saving random changes together.

9. What is a branch in Git?

A branch in Git is a separate line of development. It allows developers to work on new features, bug fixes, or experiments without disturbing the main code.

Example:

Common branch names include:

• main
• develop
• feature/payment
• bugfix/navbar
• release/v1

Branches are useful because each developer can work independently. Once the work is completed and tested, the branch can be merged into the main branch.

In real projects, branches help teams manage parallel development safely and reduce the risk of breaking stable code.

10. What is the difference between git branch and git checkout?

git branch is used to create or list branches, while git checkout is used to switch between branches or restore files.

Example:

This creates a new branch and then switches to it.

Modern Git also supports:

Simple difference:

Command	Use
git branch	Create or list branches
git checkout	Switch branch or restore files
git switch	Switch branches clearly

For freshers, remember that creating a branch and moving into that branch are two different actions.

11. What is git clone?

git clone is used to copy an existing remote repository to your local system. It downloads the project files along with Git history, branches, and remote configuration.

Example:

After cloning, you can open the project, create branches, make changes, commit them, and push back to the remote repository if you have permission.

git clone is commonly used when joining a new project or downloading code from GitHub.

Unlike simply downloading a ZIP file, cloning keeps the Git history and remote connection intact. That makes collaboration easier.

12. What is the use of git log?

The git log command shows the commit history of a repository. It displays previous commits along with commit ID, author, date, and commit message.

Example:

A simple one-line view can be shown using:

Git log helps developers understand:

• What changes were made
• Who made the changes
• When the changes happened
• Which commit introduced a feature or fix

In interviews, explain that git log is important for debugging history, reviewing work, and finding commit IDs for commands like revert, reset, or checkout.

13. What is a remote repository?

A remote repository is a version of the Git repository hosted on a server or cloud platform such as GitHub, GitLab, or Bitbucket.

Developers use remote repositories to collaborate with others.

Example:

A common remote name is origin.

Local and remote workflow:

Remote repositories help teams share code, review changes, create pull requests, and maintain backup copies of the project.

For freshers, it is important to know that Git can work locally, but collaboration usually happens through a remote repository.

14. What is the difference between git pull and git push?

git pull brings changes from the remote repository to your local repository. git push sends your local commits to the remote repository.

Command	Direction	Purpose
git pull	Remote to local	Get latest changes
git push	Local to remote	Upload your commits

Example:

In a team project, you usually pull the latest code before starting work or before pushing your changes. This reduces conflicts and keeps your local branch updated.

15. What is the difference between tracked and untracked files?

A tracked file is already known to Git. Git monitors changes made to that file. An untracked file is new and not yet added to Git tracking.

Example:

If you create a new file called about.html, Git will show it as untracked until you run:

After adding and committing it, Git starts tracking it.

File Type	Meaning
Tracked	Git knows the file
Untracked	Git does not track the file yet

This distinction is important because untracked files are not included in commits unless they are explicitly added.

16. What is git diff used for?

git diff is used to show the difference between changes in files. It helps developers review what has changed before staging or committing.

Example:

This shows changes that are not staged.

To see staged changes:

git diff is useful for:

• Reviewing code before commit
• Checking accidental changes
• Understanding file modifications
• Comparing branches or commits

For example, before committing a bug fix, a developer can run git diff to confirm that only the intended lines were changed.

It is a helpful command for writing clean and careful commits.

17. What is a merge in Git?

A merge combines changes from one branch into another branch. It is commonly used when a feature branch is completed and needs to be added to the main branch.

Example:

This brings changes from feature-login into main.

Merge is useful in team development because different developers work on separate branches. Once their work is ready, it can be merged into the shared branch.

Sometimes, Git can merge automatically. But if the same lines were changed differently in both branches, a merge conflict may occur and must be resolved manually.

18. What is a merge conflict?

A merge conflict happens when Git cannot automatically combine changes from two branches. This usually happens when the same part of a file is changed differently in both branches.

Example:

Git does not know which version to keep, so it marks the conflict.

Conflict markers may look like:

To resolve it, the developer edits the file, chooses the correct content, stages the file, and commits the resolution.

Merge conflicts are normal in team projects.

19. What is .gitignore?

.gitignore is a file used to tell Git which files or folders should not be tracked. It is useful for ignoring temporary files, build files, dependencies, logs, and sensitive configuration files.

Example .gitignore:

Files commonly ignored include:

• Environment files
• Dependency folders
• IDE settings
• Build outputs
• Log files
• Cache files

For example, in a Node.js project, node_modules should not be committed because it can be installed again using npm install.

Using .gitignore keeps the repository clean and avoids exposing unnecessary or sensitive files.

20. What is the difference between local, staging, and remote in Git?

These are three important areas in a Git workflow.

Area	Meaning
Local working directory	Where you edit files
Staging area	Where selected changes are prepared
Remote repository	Online repository shared with team

Flow:

When you edit a file, the change is in your working directory. When you run git add, it moves to staging. When you run git commit, it is saved locally. When you run git push, it goes to the remote repository.

Understanding this flow helps freshers use Git confidently.

Intermediate Git Interview Questions

These Git interview questions and answers focus on practical workflows used in real projects.

This section covers branching strategies, merge handling, commit correction, remote collaboration, stashing, tags, pull requests, and commands often asked in developer, automation testing, and DevOps interviews.

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

git fetch downloads changes from the remote repository but does not merge them into your current branch. git pull downloads changes and immediately integrates them into your local branch.

Command	What it does
git fetch	Gets remote updates safely
git pull	Gets and merges updates

Example:

Use git fetch when you want to inspect remote changes before merging. Use git pull when you trust the remote changes and want to update your local branch directly.

In team projects, git fetch gives more control, while git pull is faster for everyday updates.

2. What is the difference between merge and rebase?

Merge and rebase both integrate changes from one branch into another, but they handle history differently.

Feature	Merge	Rebase
History	Preserves branch history	Creates linear history
Commit created	Merge commit may be created	Rewrites commits
Safer for shared branches	Yes	Be careful
Best for	Collaboration	Clean local history

Example:

Merge shows the actual branch history. Rebase makes it look as if your work started from the latest main branch.

Use rebase carefully, especially on branches already shared with others, because it rewrites commit history.

3. What is git stash, and when would you use it?

git stash temporarily saves your uncommitted changes without creating a commit. It is useful when you need to switch branches quickly but are not ready to commit your current work.

Example:

Later, you can restore the changes using:

Use cases:

• Switching branch during unfinished work
• Pulling latest code safely
• Testing a quick fix
• Saving temporary changes

For example, if you are working on a feature and suddenly need to fix a production bug, you can stash your work, switch branches, fix the bug, and then return to your previous changes.

4. What is the difference between git stash apply and git stash pop?

Both commands restore stashed changes, but they behave differently.

Command	Meaning
git stash apply	Restores stash but keeps it in stash list
git stash pop	Restores stash and removes it from stash list

Example:

Use apply when you may need to reuse the same stash again. Use pop when you are sure the stash is no longer needed.

If conflicts occur while applying a stash, Git asks you to resolve them manually. The stash may remain in the list until it is safely handled.

5. What is a pull request?

A pull request is a way to propose changes from one branch to another, usually in platforms like GitHub, GitLab, or Bitbucket.

A typical workflow:

Pull requests help teams:

• Review code before merging
• Discuss changes
• Run automated checks
• Track approvals
• Maintain code quality

For example, a developer may create a branch called feature-login, push it to GitHub, and open a pull request to merge it into main.

Pull requests are important in team projects because they add review and quality control before code reaches the main branch.

6. What is the use of git cherry-pick?

git cherry-pick is used to apply a specific commit from one branch to another without merging the entire branch.

Example:

Use case:

Suppose a bug fix was committed in the develop branch, but the same fix is urgently needed in the release branch. Instead of merging all changes from develop, you can cherry-pick only the bug-fix commit.

Cherry-pick is useful but should be used carefully. It creates a new commit with the same changes, so teams should avoid overusing it when a proper merge is more suitable.

7. What is git revert?

git revert creates a new commit that undoes the changes made by an earlier commit. It does not delete commit history.

Example:

This is safe for shared branches because it keeps history clear and does not rewrite previous commits.

Use git revert when a bad commit has already been pushed to a remote branch and other developers may have pulled it.

Example scenario:

A feature is deployed but causes an issue. Instead of deleting history, the team reverts the feature commit. This keeps the repository transparent and safe for collaboration.

8. What is the difference between git reset and git revert?

git reset moves the branch pointer to a previous commit and can remove commits from local history. git revert creates a new commit that undoes an old commit.

Feature	git reset	git revert
Rewrites history	Yes	No
Safe for shared branch	Usually no	Yes
Creates new commit	No	Yes
Best for	Local cleanup	Public rollback

Use reset mainly for local work before pushing. Use revert for changes already pushed to shared branches.

9. What are soft, mixed, and hard reset?

Git reset has three common modes.

Reset Type	Effect
–soft	Moves HEAD, keeps changes staged
–mixed	Moves HEAD, keeps changes unstaged
–hard	Moves HEAD, removes changes

Example:

–soft is useful when you want to change the last commit but keep files ready to recommit.
–mixed keeps file changes but removes them from staging.
–hard deletes changes, so it should be used carefully.

In interviews, warn that git reset –hard can permanently remove uncommitted work.

10. What is a Git tag?

A Git tag is used to mark a specific commit, usually for a release version.

Example:

Tags are commonly used for:

• Software releases
• Production versions
• Milestones
• Stable builds

There are two main types:

Tag Type	Meaning
Lightweight tag	Simple pointer to commit
Annotated tag	Stores message, author, and date

For example, when version 1.0 of an application is released, the team may tag that commit as v1.0.0.

Tags make it easy to identify important points in project history.

11. What is the difference between HEAD, working tree, and index?

These are important Git concepts.

Term	Meaning
HEAD	Points to the current commit
Working tree	Files you are editing
Index	Staging area

Example workflow:

If you edit a file, the working tree changes. When you run git add, the change goes to the index. When you commit, HEAD moves to the new commit.

Understanding these concepts helps explain commands like reset, checkout, restore, and diff.

12. How do you rename a branch in Git?

A branch can be renamed using the git branch -m command.

If you are currently on the branch:

If you want to rename another branch:

If the branch is already pushed to remote, you may also need to delete the old remote branch and push the new one:

Branch renaming is useful when a branch name is incorrect, unclear, or not following naming conventions.

In teams, communicate before renaming shared branches.

13. What is upstream branch in Git?

An upstream branch is the remote branch that your local branch tracks. It allows Git to know where to pull from and push to by default.

Example:

Here, feature-login local branch is linked with origin/feature-login.

After setting upstream, you can simply run:

instead of specifying the remote and branch every time.

Upstream branches are useful in team projects because they simplify remote collaboration. If upstream is not configured,

Git may ask you to specify where to push or pull changes.

14. What is a fast-forward merge?

A fast-forward merge happens when the target branch has not changed since the feature branch was created. Git simply moves the branch pointer forward instead of creating a merge commit.

Example:

When feature is merged into main, Git moves main to C.

Fast-forward merge keeps history simple and linear.

However, some teams prefer merge commits even when fast-forward is possible because merge commits show when a

feature branch was integrated.

This can be controlled using options like:

Fast-forward merge is common in simple branch workflows.

15. What is detached HEAD in Git?

Detached HEAD means Git is pointing directly to a commit instead of a branch. This usually happens when you checkout a specific commit.

Example:

In this state, you can view or test old code, but new commits may not belong to any branch unless you create one.

To save work from detached HEAD, create a branch:

Detached HEAD is not always an error. It is useful for inspecting old commits. But if you make changes there without creating a branch, you may lose track of those commits.

16. What is git blame used for?

git blame shows who last modified each line of a file and in which commit. It is useful for understanding code history.

Example:

It displays:

• Commit ID
• Author name
• Date
• Line content

git blame should not be used to blame people personally. It is mainly used to understand why a line was changed and which commit introduced it.

For example, if a function behaves unexpectedly, git blame can help identify the related commit. Then the developer can review the commit message or pull request for context.

17. How do you delete a local and remote branch?

To delete a local branch:

If the branch is not fully merged and you still want to delete it:

To delete a remote branch:

Branch deletion is usually done after a feature branch has been merged and is no longer needed.

In real projects, deleting old branches keeps the repository clean. However, before deleting a branch, confirm that the work is merged, reviewed, or no longer required.

Be careful with shared branches because other developers may still be using them.

18. What is the difference between origin and upstream?

origin usually refers to your main remote repository. upstream often refers to the original repository when working with forks.

Example:

This is common in open-source projects.

Workflow:

If you fork a repository on GitHub, your fork becomes origin. The original project can be added as upstream.

This setup allows you to keep your fork updated with the original project while still pushing your changes to your own remote repository.

19. What is the use of git remote?

git remote is used to manage remote repository connections.

Common commands:

It helps you see which remote repositories are linked to your local repository.

Example:

Output may show:

This means your local repository is connected to a remote named origin.

Remote configuration is important because commands like git push origin main and git pull origin main depend on the correct remote URL.

20. What is a good Git commit message?

A good Git commit message clearly explains what changed and why. It should be short, meaningful, and specific.

Bad message:

Good message:

A useful commit message helps teammates understand project history without opening every file.

Good practices:

• Use present tense
• Keep it specific
• Mention the purpose
• Avoid vague words
• Keep related changes in one commit

In team projects, good commit messages improve code review, debugging, release notes, and rollback decisions.

Advanced Git Interview Questions

These advanced Git interview questions for DevOps engineer roles focus on release workflows, history rewriting, hooks, submodules, bisect, reflog, large files, CI/CD, automation testing, and repository maintenance.

These questions test whether a candidate can use Git safely in professional and production environments.

1. What is git rebase -i, and why is it used?

git rebase -i, or interactive rebase, is used to edit commit history before sharing it. It allows developers to squash commits, reorder commits, edit commit messages, or remove unnecessary commits.

Example:

Common uses:

• Combine multiple small commits
• Fix commit messages
• Remove accidental commits
• Clean feature branch history
• Prepare code before pull request

For example, instead of pushing five commits like “fix”, “again”, “final fix”, you can squash them into one meaningful commit.

Interactive rebase should be used carefully. Avoid rewriting commits already pushed to shared branches unless the team agrees.

2. What is Git reflog?

Git reflog records movements of HEAD and branch references. It helps recover commits even if they are no longer visible in normal Git log.

Example:

Reflog is useful when:

• A branch was reset accidentally
• A commit was lost after rebase
• HEAD moved unexpectedly
• You need to recover deleted work

Example recovery:

Unlike git log, which shows reachable commit history, reflog shows recent reference movements in your local repository.

For advanced Git troubleshooting, reflog is one of the most powerful recovery tools.

3. What is git bisect, and how does it help debugging?

git bisect helps find the commit that introduced a bug using binary search. It is useful when you know the code worked earlier but is broken now.

Basic flow:

Git checks out commits between good and bad versions. You test each version and mark it as good or bad.

Example:

Eventually, Git identifies the first bad commit.

This is useful in large projects where manually checking every commit would take too much time. It is a strong advanced Git debugging concept.

4. What are Git hooks?

Git hooks are scripts that run automatically when certain Git events happen. They are stored inside the .git/hooks directory.

Examples:

Hook	When it runs
pre-commit	Before commit
commit-msg	Before saving commit message
pre-push	Before push
post-merge	After merge

Use cases:

• Run lint checks
• Run unit tests
• Validate commit messages
• Prevent secrets from being committed
• Format code automatically

For example, a pre-commit hook can stop a commit if tests fail.

Git hooks are useful in automation testing, DevOps, and team workflows because they enforce quality checks before code enters the repository.

5. What is the difference between client-side and server-side Git hooks?

Client-side hooks run on a developer’s local machine, while server-side hooks run on the remote Git server.

Type	Example	Purpose
Client-side	pre-commit, pre-push	Local validation
Server-side	pre-receive, update	Central enforcement

Client-side hooks can be bypassed because they exist on local machines. Server-side hooks are stronger because they run on the central repository.

For example, a company may use a server-side hook to reject pushes to the main branch unless the commit follows a rule.

In enterprise workflows, server-side hooks are useful for enforcing security, compliance, and branch protection policies.

6. What is Git submodule?

A Git submodule allows one Git repository to include another Git repository inside it. It is useful when a project depends on another project but needs to keep it as a separate repository.

Example:

Use cases:

• Shared libraries
• Common UI components
• External dependencies
• Multiple related repositories

Submodules store a reference to a specific commit of the external repository. This gives control over which version is used.

However, submodules can be confusing for beginners because they require extra commands like:

They should be used only when separate versioning is truly needed.

7. What is Git LFS?

Git LFS, or Large File Storage, is used to manage large files in Git repositories. Normal Git is not efficient for large binary files like videos, datasets, model files, design files, or large images.

Git LFS stores large files outside the normal Git history and keeps lightweight pointers inside the repository.

Example:

Use cases:

• AI model files
• Game assets
• Large media files
• Design files
• Datasets

Git LFS helps keep repository size manageable and improves clone performance.

It is commonly useful in AI, data, design, and game development projects.

8. How does Git support CI/CD workflows?

Git supports CI/CD by acting as the source of truth for code changes. CI/CD tools like Jenkins, GitHub Actions, GitLab CI, and Azure DevOps trigger pipelines based on Git events.

Common triggers:

• Push to branch
• Pull request creation
• Merge to main
• Tag creation
• Release branch update

Example workflow:

Developer push → CI pipeline → Build → Test → Deploy

In DevOps, Git branches often represent environments or release stages. For example, merging into main may trigger production deployment.

Git also helps trace which commit was built, tested, and deployed. This makes debugging and rollback easier.

9. What is trunk-based development?

Trunk-based development is a Git workflow where developers integrate small changes frequently into a main branch, often called trunk or main.

Key practices:

• Short-lived branches
• Frequent commits
• Continuous integration
• Feature flags
• Fast code reviews
• Automated testing

This approach reduces long-running branch conflicts and supports faster delivery.

Example:

Instead of working on a feature branch for two weeks, developers push small safe changes regularly.

Trunk-based development is common in mature DevOps teams because it supports continuous delivery. However, it requires strong testing, discipline, and feature toggles to avoid releasing unfinished work.

10. What is GitFlow?

GitFlow is a branching strategy that uses multiple long-running branches for development, releases, and hotfixes.

Branch	Purpose
main	Production-ready code
develop	Ongoing development
feature/*	New features
release/*	Release preparation
hotfix/*	Urgent production fixes

GitFlow is useful for projects with scheduled releases, multiple environments, and formal release processes.

However, it can be heavier than trunk-based development. Modern teams may choose simpler workflows if they deploy frequently.

11. How would you handle a hotfix in Git?

A hotfix is an urgent fix for a production issue. In a GitFlow-style workflow, a hotfix branch is usually created from the production branch.

Example:

After fixing and testing:

The hotfix should also be merged back into development branches to avoid losing the fix.

Hotfix process should include:

• Create branch from production code
• Apply minimal fix
• Test carefully
• Merge to main
• Tag release if needed
• Merge back to develop

This keeps production fixes controlled and traceable.

12. What is squashing commits?

Squashing commits means combining multiple commits into one commit. It is often done before merging a feature branch.

Example:

Why squash?

• Clean commit history
• Remove unnecessary commits
• Make pull requests easier to review
• Group related changes together
• Improve release history

Example before squashing:

After squashing:

Squashing is useful for feature branches, but avoid squashing public shared history without agreement.

Many teams use squash merge in pull requests to keep main branch history clean.

13. What is the use of git clean?

git clean removes untracked files from the working directory. It is useful when you want to clean files that Git is not tracking.

Example:

git clean -n

The -n option shows what would be removed without deleting anything.

To actually remove files:

To remove untracked folders also:

Use cases:

• Remove generated files
• Clean temporary files
• Reset project workspace
• Remove untracked build output

Be careful because git clean can permanently delete untracked files. Always preview with git clean -n before using force.

14. How do you recover a deleted branch in Git?

If a branch was deleted but its commits still exist, you can recover it using git reflog.

Steps:

Find the commit where the branch existed, then create a new branch:

If the branch was pushed to remote, you may also recover it from the remote if it still exists:

Branch recovery depends on whether the commits are still available.

This is a practical advanced Git scenario because accidental branch deletion can happen in real projects.

15. How would you secure a Git repository?

Git repository security is important because source code may contain business logic, credentials, and sensitive configuration.

Good practices:

• Do not commit secrets
• Use .gitignore for .env files
• Enable branch protection
• Require pull request reviews
• Use signed commits if needed
• Restrict repository access
• Use SSH keys or tokens safely
• Rotate leaked credentials immediately
• Use secret scanning tools
• Avoid force push on protected branches

If a secret is committed, deleting the file in a later commit is not enough because it remains in history. The secret must be rotated and history may need cleaning.

Security should be part of Git workflow.

16. What are signed commits?

Signed commits use cryptographic signatures to verify that a commit was created by a trusted author. They help confirm commit authenticity.

Developers can sign commits using GPG or SSH signing.

Example:

Signed commits are useful in:

• Open-source projects
• Enterprise repositories
• Security-sensitive systems
• Compliance-heavy teams

On platforms like GitHub, signed commits may show as “Verified”.

They help prevent impersonation and improve trust in code history. However, signed commits do not guarantee the code is correct; they only verify the identity of the committer.

17. What is force push, and why is it risky?

Force push overwrites the remote branch history with your local branch history.

Example:

It is risky because it can remove other developers’ commits from the remote branch if your local branch is outdated.

Safer option:

–force-with-lease checks whether the remote branch has changed before overwriting it.

Force push is sometimes used after rebasing a feature branch. It should not be used on shared branches like main or develop unless there is a clear reason and team agreement.

Branch protection can prevent accidental force pushes.

18. How would you remove a sensitive file from Git history?

If a sensitive file like .env or API key is committed, first rotate the exposed secret immediately. Then remove it from Git history using tools like git filter-repo or BFG Repo-Cleaner.

Basic approach:

1. Revoke or rotate the secret.
2. Remove the file from history.
3. Add the file to .gitignore.
4. Force push cleaned history if required.
5. Inform team to re-clone or clean local copies.

Deleting the file in a new commit is not enough because the secret remains in earlier commits.

19. How does Git help automation testing teams?

Git helps automation testing teams manage test scripts, framework code, test data, and CI/CD integration.

Use cases:

• Version control for Selenium scripts
• Branching for test framework changes
• Pull requests for test code review
• Tracking changes in test cases
• Running tests through CI pipelines
• Managing environment configuration safely
• Reverting unstable automation changes

Example:

An automation tester may create a branch to update login test scripts, push it to GitHub, and trigger Jenkins to run regression tests.

20. How would you maintain a clean Git history in a large team?

Maintaining clean Git history requires process, discipline, and tooling.

Good practices include:

• Use meaningful commit messages
• Keep commits focused
• Avoid committing unrelated changes together
• Use pull requests
• Review before merging
• Squash noisy commits when appropriate
• Avoid force push on shared branches
• Delete merged feature branches
• Use branch naming conventions
• Protect main branches
• Use tags for releases

A clean history helps in debugging, rollback, release tracking, and code review.

For large teams, Git workflow should be documented clearly. Everyone should follow the same branching, commit, and merge rules to avoid confusion.

Conceptual and Scenario-based Git Interview Questions

These Git scenario based interview questions test how freshers think in real project situations.

The focus is on safe decision-making, team collaboration, mistake recovery, conflict handling, and practical Git usage in development, DevOps, and testing workflows.

1. You committed changes to the wrong branch. What would you do?

First, I would avoid panic and check whether the commit was already pushed. If it is only local, the fix is easier.

A common approach is to create a new branch from the current state:

Then go back to the wrong branch and remove the commit using reset if it was not pushed:

If the commit was already pushed to a shared branch, I would avoid rewriting history without team agreement. In that case, I may use git revert.

The correct solution depends on whether the commit is local or public.

2. You pulled the latest code and got a merge conflict. How would you resolve it?

I would first run git status to identify conflicted files. Then I would open each conflicted file and look for conflict markers.

Example:

I would carefully decide whether to keep my change, incoming change, or combine both. After editing, I would remove conflict markers, run tests, and stage the resolved file:

If the conflict is complex, I would talk to the developer who made the other change.

In real projects, conflict resolution should be tested before pushing.

3. You accidentally deleted a file and committed the deletion. How can you recover it?

If I know the commit where the file existed, I can restore it from that commit.

Example:

Then I would commit the restored file:

If I do not know the exact commit, I would use:

This shows the history of that file.

If the deletion was pushed, restoring with a new commit is safer than rewriting history.

This scenario tests whether the candidate understands Git history and file-level recovery.

4. Your teammate force-pushed and your commits disappeared from the remote branch. What would you do?

I would first check whether my local repository still has the commits. If yes, I can create a backup branch immediately.

Then I would check reflog:

If the commits are available, I can recover them using a new branch.

Next, I would communicate with the teammate and team lead before pushing anything back. Force-push issues can affect many developers, so the recovery should be coordinated.

For prevention, shared branches should have branch protection rules, and force push should be disabled on important branches.

5. You need to work on an urgent bug, but your current feature work is incomplete. What will you do?

I would use git stash to temporarily save my incomplete work.

Then I would switch to the required branch:

After fixing the bug, I would commit and push the hotfix branch. Once done, I can return to my feature branch and restore my work:

This approach avoids committing unfinished code just to switch branches.

It is a common real-world Git scenario because developers often need to pause feature work for urgent production or QA fixes.

6. You pushed a commit containing an API key. What should you do?

The first step is to rotate or revoke the exposed API key immediately. Even if the commit is deleted later, the key may already be visible in Git history.

Then I would remove the secret from the repository and add the file pattern to .gitignore.

If the key exists in history, I would use tools like BFG Repo-Cleaner or git filter-repo to remove it from past commits. After cleaning, the team may need to re-clone or reset their local repositories.

Important point: simply deleting the key in a new commit is not enough. Secrets in Git history must be treated as compromised.

7. Your pull request has many unrelated changes. What would you do before review?

I would clean the pull request before asking for review. First, I would check the changed files and separate unrelated changes.

Useful commands:

If commits are messy but local, I can use interactive rebase to squash or edit them:

If unrelated file changes are present, I would remove or move them to another branch.

A good pull request should focus on one feature or fix. Clean pull requests are easier to review, test, and merge. This shows professional Git discipline.

8. A release branch has a bug fix that is also needed in the main branch. What is the best approach?

If only one specific bug-fix commit is needed, I would use git cherry-pick.

Example:

This applies only the selected commit to the main branch without merging the entire release branch.

Before cherry-picking, I would check whether the commit depends on other changes. If it does, cherry-picking may cause issues.

After cherry-picking, I would run tests and push the change through a pull request if the team follows review process.

Cherry-pick is useful for moving selected fixes across branches.

9. Your local branch is behind the remote branch. What should you do before pushing?

I would first fetch or pull the latest changes from the remote branch.

If I need to update my branch:

If the team uses rebase workflow:

After updating, I would resolve conflicts if any, run tests, and then push my changes.

Pushing without syncing may fail or create unnecessary conflicts. In team projects, keeping the local branch updated reduces integration problems and makes collaboration smoother.

This is a common Git workflow question for freshers.

10. Your automation test branch has failing tests after merging the latest code. How would you debug it?

I would first check whether the failure is due to test script changes, application code changes, environment configuration, or dependency updates.

Steps:

• Run tests locally.
• Check merge changes using git diff.
• Review recent commits using git log.
• Identify whether locators, test data, or configuration changed.
• Compare with CI logs.
• Revert or fix only the faulty change.

If the failure started after a specific commit, git bisect can help find it.

For automation testing teams, Git history helps trace why a test started failing and whether the issue is in test code or application code.

Best Ways to Prepare for Git Interviews

• Learn Git Basics First: Start with repositories, commits, staging area, working directory, branches, merge, clone, pull, push, and remote repositories. These concepts form the base of most Git interview questions for freshers.
• Practise Git Commands Hands-on: Do not just memorize commands. Create a local repository, add files, commit changes, create branches, merge them, and push the code to GitHub.
• Understand Real Project Workflows: Learn how teams use Git in real projects through feature branches, pull requests, code reviews, merge conflicts, and release branches.
• Practise Common Git Scenarios: Prepare for situations like undoing a commit, fixing merge conflicts, reverting changes, recovering deleted files, and syncing local code with remote repositories.
• Build a GitHub Portfolio: Upload small projects, maintain proper README files, use meaningful commit messages, and show clean project structure. This helps in technical interviews and resume screening.
• Use PlacementPreparation.io: Practise Git MCQs, Git interview questions, mock tests, technical questions, and placement-focused exercises to improve interview readiness.
• Learn with GUVI and GUVI Zen Class: Use GUVI courses to learn Git, GitHub, software development, DevOps basics, web development, and full-stack workflows in a structured way. You can also choose GUVI Zen Class for mentor-led learning, hands-on projects, coding practice, and placement guidance.

Final Words

Git is a must-know tool for freshers entering software, web, DevOps, testing, and full-stack roles. Practise Git commands, branching, merging, conflict handling, GitHub workflows, and real project scenarios regularly.

Strong hands-on Git practice will help you answer Git interview questions confidently and work better in development teams.

---

---