{"id":21882,"date":"2026-06-23T10:15:19","date_gmt":"2026-06-23T04:45:19","guid":{"rendered":"https:\/\/www.placementpreparation.io\/blog\/?p=21882"},"modified":"2026-07-03T18:01:50","modified_gmt":"2026-07-03T12:31:50","slug":"git-interview-questions-for-freshers","status":"publish","type":"post","link":"https:\/\/www.placementpreparation.io\/blog\/git-interview-questions-for-freshers\/","title":{"rendered":"Top 50+ Git Interview Questions for Freshers"},"content":{"rendered":"<?xml encoding=\"utf-8\" ?><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p><strong>Key Takeaways<\/strong><\/p>\n<p>In this article, we will learn about:<\/p>\n<ul>\n<li>Basic Git concepts like repositories, commits, branches, staging area, and working directory.<\/li>\n<li>Important Git interview questions for freshers asked in technical and developer interviews.<\/li>\n<li>The difference between Git and GitHub in a simple, interview-friendly way.<\/li>\n<li>Common Git commands like git init, git add, git commit, git status, git log, git clone, git pull, and git push.<\/li>\n<li>Branching, merging, rebasing, conflict resolution, and remote repository workflows.<\/li>\n<li>Practical Git scenarios related to wrong commits, deleted files, merge conflicts, pull requests, and team collaboration.<\/li>\n<li>Best ways to prepare for Git interviews through hands-on practice, <a href=\"https:\/\/www.placementpreparation.io\/mock-test\">mock tests<\/a>, and real GitHub projects.<\/li>\n<\/ul>\n<\/div><\/div><p>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.<\/p><p>According to <a href=\"https:\/\/github.blog\/news-insights\/octoverse\/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1\/\" rel=\"nofollow noopener\" target=\"_blank\">GitHub&rsquo;s Octoverse 2025 report<\/a>, GitHub crossed 180 million developers and 630 million projects, showing how widely Git-based collaboration is used in modern software development.<\/p><p>This article covers practical Git interview questions for freshers with clear answers, examples, and real project-based explanations.<\/p><p><a href=\"https:\/\/www.placementpreparation.io\/mock-test\/?utm_source=placement_preparation&amp;utm_medium=blog_banner&amp;utm_campaign=git_interview_questions_for_freshers_horizontal\"><img decoding=\"async\" class=\"alignnone wp-image-21216 size-full\" src=\"https:\/\/www.placementpreparation.io\/blog\/wp-content\/uploads\/2026\/06\/mock-test-horizontal-banner-placement-success.webp\" alt=\"mock test horizontal banner placement success\" width=\"1135\" height=\"300\" srcset=\"https:\/\/www.placementpreparation.io\/blog\/wp-content\/uploads\/2026\/06\/mock-test-horizontal-banner-placement-success.webp 1135w, https:\/\/www.placementpreparation.io\/blog\/wp-content\/uploads\/2026\/06\/mock-test-horizontal-banner-placement-success-300x79.webp 300w, https:\/\/www.placementpreparation.io\/blog\/wp-content\/uploads\/2026\/06\/mock-test-horizontal-banner-placement-success-1024x271.webp 1024w, https:\/\/www.placementpreparation.io\/blog\/wp-content\/uploads\/2026\/06\/mock-test-horizontal-banner-placement-success-768x203.webp 768w, https:\/\/www.placementpreparation.io\/blog\/wp-content\/uploads\/2026\/06\/mock-test-horizontal-banner-placement-success-150x40.webp 150w\" sizes=\"(max-width: 1135px) 100vw, 1135px\"><\/a><\/p><h2>Beginner Git Interview Questions<\/h2><p>These Git basic interview questions are useful for freshers who are learning version control for software development, DevOps, automation testing, and full-stack roles.<\/p><p>This section covers the foundation of Git: repositories, commits, branches, staging, remotes, and everyday commands used in real projects.<\/p><h3>1. What is Git, and why is it used?<\/h3><p>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.<\/p><p>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&rsquo;s work.<\/p><p>Git is used for:<\/p><ul>\n<li>Tracking code history<\/li>\n<li>Working on branches<\/li>\n<li>Collaborating with teams<\/li>\n<li>Reverting mistakes<\/li>\n<li>Managing releases<\/li>\n<li>Supporting DevOps workflows<\/li>\n<\/ul><p>For freshers, Git is important because almost every software team uses it in day-to-day development.<\/p><h3>2. What is the difference between Git and GitHub?<\/h3><p>Git is a version control tool installed on your system, while GitHub is a cloud-based platform used to host Git repositories online.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Feature<\/b><\/td>\n<td><b>Git<\/b><\/td>\n<td><b>GitHub<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">Type<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Version control system<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Hosting platform<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Works<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Locally<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Online<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Used for<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Tracking changes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Collaboration and sharing<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Example<\/span><\/td>\n<td><span style=\"font-weight: 400;\">git commit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Pull request<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>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.<\/p><h3>3. What is a Git repository?<\/h3><p>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.<\/p><p>A repository can be:<\/p><ul>\n<li><strong>Local repository:<\/strong> Stored on your computer<\/li>\n<li><strong>Remote repository:<\/strong> Stored on platforms like GitHub, GitLab, or Bitbucket<\/li>\n<\/ul><p>When you run:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git init<\/p>\n<\/div><\/div><p>Git creates a hidden .git folder inside the project. This folder stores metadata, commit history, branches, and configuration.<\/p><p>In simple terms, a repository is not just a folder with files. It is a tracked project where Git remembers every committed change.<\/p><h3>4. What is the staging area in Git?<\/h3><p>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.<\/p><p>Flow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>Working Directory &rarr; Staging Area &rarr; Commit<\/p>\n<\/div><\/div><p>For example, after editing three files, you may want to commit only two of them. You can stage only those two files using:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git add file1.txt file2.txt<\/p>\n<\/div><\/div><p>Then commit them.<\/p><p>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.<\/p><h3>5. What is a commit in Git?<\/h3><p>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.<\/p><p>A commit usually contains:<\/p><ul>\n<li>Changed files<\/li>\n<li>Author details<\/li>\n<li>Timestamp<\/li>\n<li>Commit message<\/li>\n<li>Unique commit ID<\/li>\n<\/ul><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git commit -m &ldquo;Add login validation&rdquo;<\/p>\n<\/div><\/div><p>A good commit message should clearly explain the purpose of the change. For example, &ldquo;Fix login button alignment&rdquo; is better than &ldquo;changes done&rdquo;.<\/p><p>Commits help developers review project history, revert mistakes, and understand how the code evolved over time.<\/p><h3>6. What is the use of git init?<\/h3><p>The <strong>git init<\/strong> command is used to create a new Git repository in an existing folder. When this command is executed, Git creates a hidden <strong>.git<\/strong> directory inside the project.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git init<\/p>\n<\/div><\/div><p>After running this command, Git starts tracking the project. You can then add files, create commits, and manage history.<\/p><p>Typical flow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>mkdir my-project<br>\ncd my-project<br>\ngit init<\/p>\n<\/div><\/div><p>This command is mostly used when starting a new project locally. If you are downloading an existing project from GitHub, you usually use <strong>git clone<\/strong> instead of <strong>git init<\/strong>.<\/p><h3>7. What does git status show?<\/h3><p>The <strong>git status<\/strong> 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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git status<\/p>\n<\/div><\/div><p>It can show:<\/p><ul>\n<li>Files changed but not staged<\/li>\n<li>Files staged for commit<\/li>\n<li>New untracked files<\/li>\n<li>Current branch name<\/li>\n<li>Whether local branch is ahead or behind remote<\/li>\n<\/ul><p>For freshers, this is one of the most useful commands because it helps avoid confusion before committing.<\/p><p>A good habit is to run git status before git add, before git commit, and before pushing code to a remote repository.<\/p><h3>8. What is the difference between git add and git commit?<\/h3><p><strong>git add<\/strong> moves changes to the staging area, while <strong>git commit<\/strong> saves those staged changes into Git history.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Command<\/b><\/td>\n<td><b>Purpose<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">git add<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Selects changes for commit<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">git commit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Saves staged changes permanently<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git add index.html<\/p>\n<p>git commit -m &ldquo;Update homepage layout&rdquo;<\/p>\n<\/div><\/div><p>If you modify a file but do not run git add, Git will not include that change in the next commit.<\/p><p>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.<\/p><h3>9. What is a branch in Git?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git branch feature-login<\/p>\n<\/div><\/div><p>Common branch names include:<\/p><ul>\n<li><strong>main<\/strong><\/li>\n<li><strong>develop<\/strong><\/li>\n<li><strong>feature\/payment<\/strong><\/li>\n<li><strong>bugfix\/navbar<\/strong><\/li>\n<li><strong>release\/v1<\/strong><\/li>\n<\/ul><p>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.<\/p><p>In real projects, branches help teams manage parallel development safely and reduce the risk of breaking stable code.<\/p><h3>10. What is the difference between git branch and git checkout?<\/h3><p><strong>git branch<\/strong> is used to create or list branches, while <strong>git checkout<\/strong> is used to switch between branches or restore files.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git branch feature-login<br>\ngit checkout feature-login<\/p>\n<\/div><\/div><p>This creates a new branch and then switches to it.<\/p><p>Modern Git also supports:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git switch feature-login<\/p>\n<\/div><\/div><p>Simple difference:<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Command<\/b><\/td>\n<td><b>Use<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><strong>git branch<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Create or list branches<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>git checkout<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Switch branch or restore files<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>git switch<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Switch branches clearly<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>For freshers, remember that creating a branch and moving into that branch are two different actions.<\/p><h3>11. What is git clone?<\/h3><p><strong>git clone<\/strong> 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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git clone https:\/\/github.com\/user\/project.git<\/p>\n<\/div><\/div><p>After cloning, you can open the project, create branches, make changes, commit them, and push back to the remote repository if you have permission.<\/p><p><strong>git clone<\/strong> is commonly used when joining a new project or downloading code from GitHub.<\/p><p>Unlike simply downloading a ZIP file, cloning keeps the Git history and remote connection intact. That makes collaboration easier.<\/p><h3>12. What is the use of git log?<\/h3><p>The <strong>git log<\/strong> command shows the commit history of a repository. It displays previous commits along with commit ID, author, date, and commit message.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git log<\/p>\n<\/div><\/div><p>A simple one-line view can be shown using:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git log &ndash;oneline<\/p>\n<\/div><\/div><p>Git log helps developers understand:<\/p><ul>\n<li>What changes were made<\/li>\n<li>Who made the changes<\/li>\n<li>When the changes happened<\/li>\n<li>Which commit introduced a feature or fix<\/li>\n<\/ul><p>In interviews, explain that <strong>git log<\/strong> is important for debugging history, reviewing work, and finding commit IDs for commands like revert, reset, or checkout.<\/p><h3>13. What is a remote repository?<\/h3><p>A remote repository is a version of the Git repository hosted on a server or cloud platform such as GitHub, GitLab, or Bitbucket.<\/p><p>Developers use remote repositories to collaborate with others.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git remote -v<\/p>\n<\/div><\/div><p>A common remote name is <strong>origin<\/strong>.<\/p><p>Local and remote workflow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>Local Repository &rarr; Push &rarr; Remote Repository<br>\nRemote Repository &rarr; Pull &rarr; Local Repository<\/p>\n<\/div><\/div><p>Remote repositories help teams share code, review changes, create pull requests, and maintain backup copies of the project.<\/p><p>For freshers, it is important to know that Git can work locally, but collaboration usually happens through a remote repository.<\/p><h3>14. What is the difference between git pull and git push?<\/h3><p>git pull brings changes from the remote repository to your local repository. git push sends your local commits to the remote repository.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Command<\/b><\/td>\n<td><b>Direction<\/b><\/td>\n<td><b>Purpose<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><strong>git pull<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Remote to local<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Get latest changes<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>git push<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Local to remote<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Upload your commits<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git pull origin main<br>\ngit push origin main<\/p>\n<\/div><\/div><p>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.<\/p><h3>15. What is the difference between tracked and untracked files?<\/h3><p>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.<\/p><p>Example:<\/p><p>If you create a new file called <strong>about.html<\/strong>, Git will show it as untracked until you run:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git add about.html<\/p>\n<\/div><\/div><p>After adding and committing it, Git starts tracking it.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>File Type<\/b><\/td>\n<td><b>Meaning<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">Tracked<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Git knows the file<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Untracked<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Git does not track the file yet<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>This distinction is important because untracked files are not included in commits unless they are explicitly added.<\/p><h3>16. What is git diff used for?<\/h3><p>git diff is used to show the difference between changes in files. It helps developers review what has changed before staging or committing.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git diff<\/p>\n<\/div><\/div><p>This shows changes that are not staged.<\/p><p>To see staged changes:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git diff &ndash;staged<\/p>\n<\/div><\/div><p><strong>git diff<\/strong> is useful for:<\/p><ul>\n<li>Reviewing code before commit<\/li>\n<li>Checking accidental changes<\/li>\n<li>Understanding file modifications<\/li>\n<li>Comparing branches or commits<\/li>\n<\/ul><p>For example, before committing a bug fix, a developer can run git diff to confirm that only the intended lines were changed.<\/p><p>It is a helpful command for writing clean and careful commits.<\/p><h3>17. What is a merge in Git?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout main<br>\ngit merge feature-login<\/p>\n<\/div><\/div><p>This brings changes from feature-login into main.<\/p><p>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.<\/p><p>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.<\/p><h3>18. What is a merge conflict?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>Developer A changes a button text to &ldquo;Login&rdquo;.<br>\nDeveloper B changes the same button text to &ldquo;Sign In&rdquo;.<\/p>\n<\/div><\/div><p>Git does not know which version to keep, so it marks the conflict.<\/p><p>Conflict markers may look like:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD<br>\nLogin<br>\n=======<br>\nSign In<br>\n&gt;&gt;&gt;&gt;&gt;&gt;&gt; feature-branch<\/p>\n<\/div><\/div><p>To resolve it, the developer edits the file, chooses the correct content, stages the file, and commits the resolution.<\/p><p>Merge conflicts are normal in team projects.<\/p><h3>19. What is .gitignore?<\/h3><p>.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.<\/p><p>Example <strong>.gitignore:<\/strong><\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>node_modules\/<br>\n.env<br>\n*.log<br>\ndist\/<\/p>\n<\/div><\/div><p>Files commonly ignored include:<\/p><ul>\n<li>Environment files<\/li>\n<li>Dependency folders<\/li>\n<li>IDE settings<\/li>\n<li>Build outputs<\/li>\n<li>Log files<\/li>\n<li>Cache files<\/li>\n<\/ul><p>For example, in a Node.js project, node_modules should not be committed because it can be installed again using npm install.<\/p><p>Using .gitignore keeps the repository clean and avoids exposing unnecessary or sensitive files.<\/p><h3>20. What is the difference between local, staging, and remote in Git?<\/h3><p>These are three important areas in a Git workflow.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Area<\/b><\/td>\n<td><b>Meaning<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">Local working directory<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Where you edit files<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Staging area<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Where selected changes are prepared<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Remote repository<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Online repository shared with team<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Flow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p><strong>Edit file &rarr; git add &rarr; git commit &rarr; git push<\/strong><\/p>\n<\/div><\/div><p>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.<\/p><p>Understanding this flow helps freshers use Git confidently.<\/p><h2>Intermediate Git Interview Questions<\/h2><p>These Git interview questions and answers focus on practical workflows used in real projects.<\/p><p>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.<\/p><h3>1. What is the difference between git fetch and git pull?<\/h3><p><strong>git fetch<\/strong> downloads changes from the remote repository but does not merge them into your current branch. <strong>git pull<\/strong> downloads changes and immediately integrates them into your local branch.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Command<\/b><\/td>\n<td><b>What it does<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">git fetch<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Gets remote updates safely<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">git pull<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Gets and merges updates<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git fetch origin<\/p>\n<p>git pull origin main<\/p>\n<\/div><\/div><p>Use <strong>git fetch<\/strong> when you want to inspect remote changes before merging. Use <strong>git pull<\/strong> when you trust the remote changes and want to update your local branch directly.<\/p><p>In team projects, git fetch gives more control, while git pull is faster for everyday updates.<\/p><h3>2. What is the difference between merge and rebase?<\/h3><p>Merge and rebase both integrate changes from one branch into another, but they handle history differently.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Feature<\/b><\/td>\n<td><b>Merge<\/b><\/td>\n<td><b>Rebase<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">History<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Preserves branch history<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Creates linear history<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Commit created<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Merge commit may be created<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Rewrites commits<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Safer for shared branches<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Be careful<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Best for<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Collaboration<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Clean local history<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git merge main<\/p>\n<p>git rebase main<\/p>\n<\/div><\/div><p>Merge shows the actual branch history. Rebase makes it look as if your work started from the latest main branch.<\/p><p>Use rebase carefully, especially on branches already shared with others, because it rewrites commit history.<\/p><h3>3. What is git stash, and when would you use it?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git stash<\/p>\n<p>git checkout main<\/p>\n<\/div><\/div><p>Later, you can restore the changes using:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git stash pop<\/p>\n<\/div><\/div><p>Use cases:<\/p><ul>\n<li>Switching branch during unfinished work<\/li>\n<li>Pulling latest code safely<\/li>\n<li>Testing a quick fix<\/li>\n<li>Saving temporary changes<\/li>\n<\/ul><p>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.<\/p><h3>4. What is the difference between git stash apply and git stash pop?<\/h3><p>Both commands restore stashed changes, but they behave differently.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Command<\/b><\/td>\n<td><b>Meaning<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><strong>git stash apply<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Restores stash but keeps it in stash list<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>git stash pop<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Restores stash and removes it from stash list<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git stash apply<\/p>\n<p>git stash pop<\/p>\n<\/div><\/div><p>Use apply when you may need to reuse the same stash again. Use pop when you are sure the stash is no longer needed.<\/p><p>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.<\/p><h3>5. What is a pull request?<\/h3><p>A pull request is a way to propose changes from one branch to another, usually in platforms like GitHub, GitLab, or Bitbucket.<\/p><p>A typical workflow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p><strong>Create branch &rarr; Commit changes &rarr; Push branch &rarr; Open pull request &rarr; Review &rarr; Merge<\/strong><\/p>\n<\/div><\/div><p>Pull requests help teams:<\/p><ul>\n<li>Review code before merging<\/li>\n<li>Discuss changes<\/li>\n<li>Run automated checks<\/li>\n<li>Track approvals<\/li>\n<li>Maintain code quality<\/li>\n<\/ul><p>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.<\/p><p>Pull requests are important in team projects because they add review and quality control before code reaches the main branch.<\/p><h3>6. What is the use of git cherry-pick?<\/h3><p><strong>git cherry-pick<\/strong> is used to apply a specific commit from one branch to another without merging the entire branch.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git cherry-pick a1b2c3d<\/p>\n<\/div><\/div><p>Use case:<\/p><p>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.<\/p><p>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.<\/p><h3>7. What is git revert?<\/h3><p><strong>git revert<\/strong> creates a new commit that undoes the changes made by an earlier commit. It does not delete commit history.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git revert a1b2c3d<\/p>\n<\/div><\/div><p>This is safe for shared branches because it keeps history clear and does not rewrite previous commits.<\/p><p>Use git revert when a bad commit has already been pushed to a remote branch and other developers may have pulled it.<\/p><p>Example scenario:<\/p><p>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.<\/p><h3>8. What is the difference between git reset and git revert?<\/h3><p>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.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Feature<\/b><\/td>\n<td><b>git reset<\/b><\/td>\n<td><b>git revert<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">Rewrites history<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">No<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Safe for shared branch<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Usually no<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Creates new commit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">No<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Yes<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Best for<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Local cleanup<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Public rollback<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Use <strong>reset<\/strong> mainly for local work before pushing. Use revert for changes already pushed to shared branches.<\/p><h3>9. What are soft, mixed, and hard reset?<\/h3><p>Git reset has three common modes.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Reset Type<\/b><\/td>\n<td><b>Effect<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><strong>&ndash;soft<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Moves HEAD, keeps changes staged<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>&ndash;mixed<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Moves HEAD, keeps changes unstaged<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>&ndash;hard<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Moves HEAD, removes changes<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git reset &ndash;soft HEAD~1<\/p>\n<p>git reset &ndash;mixed HEAD~1<\/p>\n<p>git reset &ndash;hard HEAD~1<\/p>\n<\/div><\/div><p><strong>&ndash;soft<\/strong> is useful when you want to change the last commit but keep files ready to recommit.<br>\n<strong>&ndash;mixed<\/strong> keeps file changes but removes them from staging.<br>\n<strong>&ndash;hard<\/strong> deletes changes, so it should be used carefully.<\/p><p>In interviews, warn that git reset &ndash;hard can permanently remove uncommitted work.<\/p><h3>10. What is a Git tag?<\/h3><p>A Git tag is used to mark a specific commit, usually for a release version.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git tag v1.0.0<\/p>\n<p>git push origin v1.0.0<\/p>\n<\/div><\/div><p>Tags are commonly used for:<\/p><ul>\n<li>Software releases<\/li>\n<li>Production versions<\/li>\n<li>Milestones<\/li>\n<li>Stable builds<\/li>\n<\/ul><p>There are two main types:<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Tag Type<\/b><\/td>\n<td><b>Meaning<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">Lightweight tag<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Simple pointer to commit<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Annotated tag<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Stores message, author, and date<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>For example, when version 1.0 of an application is released, the team may tag that commit as <strong>v1.0.0<\/strong>.<\/p><p>Tags make it easy to identify important points in project history.<\/p><h3>11. What is the difference between HEAD, working tree, and index?<\/h3><p>These are important Git concepts.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Term<\/b><\/td>\n<td><b>Meaning<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">HEAD<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Points to the current commit<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Working tree<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Files you are editing<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Index<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Staging area<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Example workflow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>HEAD &rarr; Last committed version<\/p>\n<p>Working tree &rarr; Current file changes<\/p>\n<p>Index &rarr; Changes selected for commit<\/p>\n<\/div><\/div><p>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.<\/p><p>Understanding these concepts helps explain commands like reset, checkout, restore, and diff.<\/p><h3>12. How do you rename a branch in Git?<\/h3><p>A branch can be renamed using the git branch -m command.<\/p><p>If you are currently on the branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git branch -m new-branch-name<\/p>\n<\/div><\/div><p>If you want to rename another branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git branch -m old-name new-name<\/p>\n<\/div><\/div><p>If the branch is already pushed to remote, you may also need to delete the old remote branch and push the new one:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git push origin &ndash;delete old-name<\/p>\n<p>git push origin new-name<\/p>\n<\/div><\/div><p>Branch renaming is useful when a branch name is incorrect, unclear, or not following naming conventions.<\/p><p>In teams, communicate before renaming shared branches.<\/p><h3>13. What is upstream branch in Git?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git push -u origin feature-login<\/p>\n<\/div><\/div><p>Here, feature-login local branch is linked with <strong>origin\/feature-login<\/strong>.<\/p><p>After setting upstream, you can simply run:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git pull<\/p>\n<p>git push<\/p>\n<\/div><\/div><p>instead of specifying the remote and branch every time.<\/p><p>Upstream branches are useful in team projects because they simplify remote collaboration. If upstream is not configured,<\/p><p>Git may ask you to specify where to push or pull changes.<\/p><h3>14. What is a fast-forward merge?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>main: A &rarr; B<\/p>\n<p>feature: A &rarr; B &rarr; C<\/p>\n<\/div><\/div><p>When feature is merged into main, Git moves main to C.<\/p><p>Fast-forward merge keeps history simple and linear.<\/p><p>However, some teams prefer merge commits even when fast-forward is possible because merge commits show when a<\/p><p>feature branch was integrated.<\/p><p>This can be controlled using options like:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git merge &ndash;no-ff feature-branch<\/p>\n<\/div><\/div><p>Fast-forward merge is common in simple branch workflows.<\/p><h3>15. What is detached HEAD in Git?<\/h3><p>Detached HEAD means Git is pointing directly to a commit instead of a branch. This usually happens when you checkout a specific commit.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout a1b2c3d<\/p>\n<\/div><\/div><p>In this state, you can view or test old code, but new commits may not belong to any branch unless you create one.<\/p><p>To save work from detached HEAD, create a branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout -b new-branch<\/p>\n<\/div><\/div><p>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.<\/p><h3>16. What is git blame used for?<\/h3><p><strong>git blame<\/strong> shows who last modified each line of a file and in which commit. It is useful for understanding code history.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git blame app.js<\/p>\n<\/div><\/div><p>It displays:<\/p><ul>\n<li>Commit ID<\/li>\n<li>Author name<\/li>\n<li>Date<\/li>\n<li>Line content<\/li>\n<\/ul><p>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.<\/p><p>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.<\/p><h3>17. How do you delete a local and remote branch?<\/h3><p>To delete a local branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git branch -d feature-login<\/p>\n<\/div><\/div><p>If the branch is not fully merged and you still want to delete it:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git branch -D feature-login<\/p>\n<\/div><\/div><p>To delete a remote branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git push origin &ndash;delete feature-login<\/p>\n<\/div><\/div><p>Branch deletion is usually done after a feature branch has been merged and is no longer needed.<\/p><p>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.<\/p><p>Be careful with shared branches because other developers may still be using them.<\/p><h3>18. What is the difference between origin and upstream?<\/h3><p><strong>origin<\/strong> usually refers to your main remote repository. upstream often refers to the original repository when working with forks.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>origin &rarr; Your fork<\/p>\n<p>upstream &rarr; Original project repository<\/p>\n<\/div><\/div><p>This is common in open-source projects.<\/p><p>Workflow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git fetch upstream<\/p>\n<p>git merge upstream\/main<\/p>\n<p>git push origin main<\/p>\n<\/div><\/div><p>If you fork a repository on GitHub, your fork becomes <strong>origin<\/strong>. The original project can be added as <strong>upstream<\/strong>.<\/p><p>This setup allows you to keep your fork updated with the original project while still pushing your changes to your own remote repository.<\/p><h3>19. What is the use of git remote?<\/h3><p><strong>git remote<\/strong> is used to manage remote repository connections.<\/p><p>Common commands:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git remote -v<\/p>\n<p>git remote add origin &lt;url&gt;<\/p>\n<p>git remote remove origin<\/p>\n<\/div><\/div><p>It helps you see which remote repositories are linked to your local repository.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git remote -v<\/p>\n<\/div><\/div><p>Output may show:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>origin https:\/\/github.com\/user\/project.git<\/p>\n<\/div><\/div><p>This means your local repository is connected to a remote named origin.<\/p><p>Remote configuration is important because commands like git push origin main and git pull origin main depend on the correct remote URL.<\/p><h3>20. What is a good Git commit message?<\/h3><p>A good Git commit message clearly explains what changed and why. It should be short, meaningful, and specific.<\/p><p>Bad message:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>changes<\/p>\n<\/div><\/div><p>Good message:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>Fix login validation for empty password<\/p>\n<\/div><\/div><p>A useful commit message helps teammates understand project history without opening every file.<\/p><p>Good practices:<\/p><ul>\n<li>Use present tense<\/li>\n<li>Keep it specific<\/li>\n<li>Mention the purpose<\/li>\n<li>Avoid vague words<\/li>\n<li>Keep related changes in one commit<\/li>\n<\/ul><p>In team projects, good commit messages improve code review, debugging, release notes, and rollback decisions.<\/p><h2>Advanced Git Interview Questions<\/h2><p>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.<\/p><p>These questions test whether a candidate can use Git safely in professional and production environments.<\/p><h3>1. What is git rebase -i, and why is it used?<\/h3><p><strong>git rebase -i<\/strong>, 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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git rebase -i HEAD~3<\/p>\n<\/div><\/div><p>Common uses:<\/p><ul>\n<li>Combine multiple small commits<\/li>\n<li>Fix commit messages<\/li>\n<li>Remove accidental commits<\/li>\n<li>Clean feature branch history<\/li>\n<li>Prepare code before pull request<\/li>\n<\/ul><p>For example, instead of pushing five commits like &ldquo;fix&rdquo;, &ldquo;again&rdquo;, &ldquo;final fix&rdquo;, you can squash them into one meaningful commit.<\/p><p>Interactive rebase should be used carefully. Avoid rewriting commits already pushed to shared branches unless the team agrees.<\/p><h3>2. What is Git reflog?<\/h3><p>Git reflog records movements of HEAD and branch references. It helps recover commits even if they are no longer visible in normal Git log.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git reflog<\/p>\n<\/div><\/div><p>Reflog is useful when:<\/p><ul>\n<li>A branch was reset accidentally<\/li>\n<li>A commit was lost after rebase<\/li>\n<li>HEAD moved unexpectedly<\/li>\n<li>You need to recover deleted work<\/li>\n<\/ul><p>Example recovery:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout a1b2c3d<\/p>\n<p>git checkout -b recovered-work<\/p>\n<\/div><\/div><p>Unlike git log, which shows reachable commit history, reflog shows recent reference movements in your local repository.<\/p><p>For advanced Git troubleshooting, reflog is one of the most powerful recovery tools.<\/p><h3>3. What is git bisect, and how does it help debugging?<\/h3><p>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.<\/p><p>Basic flow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git bisect start<\/p>\n<p>git bisect bad<\/p>\n<p>git bisect good &lt;old-good-commit&gt;<\/p>\n<\/div><\/div><p>Git checks out commits between good and bad versions. You test each version and mark it as good or bad.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git bisect good<\/p>\n<p>git bisect bad<\/p>\n<\/div><\/div><p>Eventually, Git identifies the first bad commit.<\/p><p>This is useful in large projects where manually checking every commit would take too much time. It is a strong advanced Git debugging concept.<\/p><h3>4. What are Git hooks?<\/h3><p>Git hooks are scripts that run automatically when certain Git events happen. They are stored inside the .git\/hooks directory.<\/p><p>Examples:<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Hook<\/b><\/td>\n<td><b>When it runs<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><span style=\"font-weight: 400;\">pre-commit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Before commit<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">commit-msg<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Before saving commit message<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">pre-push<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Before push<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">post-merge<\/span><\/td>\n<td><span style=\"font-weight: 400;\">After merge<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Use cases:<\/p><ul>\n<li>Run lint checks<\/li>\n<li>Run unit tests<\/li>\n<li>Validate commit messages<\/li>\n<li>Prevent secrets from being committed<\/li>\n<li>Format code automatically<\/li>\n<\/ul><p>For example, a pre-commit hook can stop a commit if tests fail.<\/p><p>Git hooks are useful in automation testing, DevOps, and team workflows because they enforce quality checks before code enters the repository.<\/p><h3>5. What is the difference between client-side and server-side Git hooks?<\/h3><p>Client-side hooks run on a developer&rsquo;s local machine, while server-side hooks run on the remote Git server.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Type<\/b><\/td>\n<td><b>Example<\/b><\/td>\n<td><b>Purpose<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td>Client-side<\/td>\n<td>pre-commit, pre-push<\/td>\n<td>Local validation<\/td>\n<\/tr>\n<tr>\n<td>Server-side<\/td>\n<td>pre-receive, update<\/td>\n<td>Central enforcement<\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>Client-side hooks can be bypassed because they exist on local machines. Server-side hooks are stronger because they run on the central repository.<\/p><p>For example, a company may use a server-side hook to reject pushes to the main branch unless the commit follows a rule.<\/p><p>In enterprise workflows, server-side hooks are useful for enforcing security, compliance, and branch protection policies.<\/p><h3>6. What is Git submodule?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git submodule add https:\/\/github.com\/company\/shared-lib.git libs\/shared-lib<\/p>\n<\/div><\/div><p>Use cases:<\/p><ul>\n<li>Shared libraries<\/li>\n<li>Common UI components<\/li>\n<li>External dependencies<\/li>\n<li>Multiple related repositories<\/li>\n<\/ul><p>Submodules store a reference to a specific commit of the external repository. This gives control over which version is used.<\/p><p>However, submodules can be confusing for beginners because they require extra commands like:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git submodule update &ndash;init &ndash;recursive<\/p>\n<\/div><\/div><p>They should be used only when separate versioning is truly needed.<\/p><h3>7. What is Git LFS?<\/h3><p>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.<\/p><p>Git LFS stores large files outside the normal Git history and keeps lightweight pointers inside the repository.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git lfs track &ldquo;*.psd&rdquo;<\/p>\n<p>git add .gitattributes<\/p>\n<\/div><\/div><p>Use cases:<\/p><ul>\n<li>AI model files<\/li>\n<li>Game assets<\/li>\n<li>Large media files<\/li>\n<li>Design files<\/li>\n<li>Datasets<\/li>\n<\/ul><p>Git LFS helps keep repository size manageable and improves clone performance.<\/p><p>It is commonly useful in AI, data, design, and game development projects.<\/p><h3>8. How does Git support CI\/CD workflows?<\/h3><p>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.<\/p><p>Common triggers:<\/p><ul>\n<li>Push to branch<\/li>\n<li>Pull request creation<\/li>\n<li>Merge to main<\/li>\n<li>Tag creation<\/li>\n<li>Release branch update<\/li>\n<\/ul><p>Example workflow:<\/p><p><strong>Developer push &rarr; CI pipeline &rarr; Build &rarr; Test &rarr; Deploy<\/strong><\/p><p>In DevOps, Git branches often represent environments or release stages. For example, merging into main may trigger production deployment.<\/p><p>Git also helps trace which commit was built, tested, and deployed. This makes debugging and rollback easier.<\/p><h3>9. What is trunk-based development?<\/h3><p>Trunk-based development is a Git workflow where developers integrate small changes frequently into a main branch, often called trunk or main.<\/p><p>Key practices:<\/p><ul>\n<li>Short-lived branches<\/li>\n<li>Frequent commits<\/li>\n<li>Continuous integration<\/li>\n<li>Feature flags<\/li>\n<li>Fast code reviews<\/li>\n<li>Automated testing<\/li>\n<\/ul><p>This approach reduces long-running branch conflicts and supports faster delivery.<\/p><p>Example:<\/p><p>Instead of working on a feature branch for two weeks, developers push small safe changes regularly.<\/p><p>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.<\/p><h3>10. What is GitFlow?<\/h3><p>GitFlow is a branching strategy that uses multiple long-running branches for development, releases, and hotfixes.<\/p><table class=\"tablepress\">\n<thead><tr>\n<td><b>Branch<\/b><\/td>\n<td><b>Purpose<\/b><\/td>\n<\/tr><\/thead><tbody class=\"row-striping row-hover\">\n\n<tr>\n<td><strong>main<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Production-ready code<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>develop<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Ongoing development<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>feature\/*<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">New features<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>release\/*<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Release preparation<\/span><\/td>\n<\/tr>\n<tr>\n<td><strong>hotfix\/*<\/strong><\/td>\n<td><span style=\"font-weight: 400;\">Urgent production fixes<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table><p>GitFlow is useful for projects with scheduled releases, multiple environments, and formal release processes.<\/p><p>However, it can be heavier than trunk-based development. Modern teams may choose simpler workflows if they deploy frequently.<\/p><h3>11. How would you handle a hotfix in Git?<\/h3><p>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.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout main<\/p>\n<p>git checkout -b hotfix\/payment-error<\/p>\n<\/div><\/div><p>After fixing and testing:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git commit -m &ldquo;Fix payment timeout handling&rdquo;<\/p>\n<p>git checkout main<\/p>\n<p>git merge hotfix\/payment-error<\/p>\n<\/div><\/div><p>The hotfix should also be merged back into development branches to avoid losing the fix.<\/p><p>Hotfix process should include:<\/p><ul>\n<li>Create branch from production code<\/li>\n<li>Apply minimal fix<\/li>\n<li>Test carefully<\/li>\n<li>Merge to main<\/li>\n<li>Tag release if needed<\/li>\n<li>Merge back to develop<\/li>\n<\/ul><p>This keeps production fixes controlled and traceable.<\/p><h3>12. What is squashing commits?<\/h3><p>Squashing commits means combining multiple commits into one commit. It is often done before merging a feature branch.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git rebase -i HEAD~4<\/p>\n<\/div><\/div><p>Why squash?<\/p><ul>\n<li>Clean commit history<\/li>\n<li>Remove unnecessary commits<\/li>\n<li>Make pull requests easier to review<\/li>\n<li>Group related changes together<\/li>\n<li>Improve release history<\/li>\n<\/ul><p>Example before squashing:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>Add login page<\/p>\n<p>fix typo<\/p>\n<p>update button<\/p>\n<p>final changes<\/p>\n<\/div><\/div><p>After squashing:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>Add login page with validation<\/p>\n<\/div><\/div><p>Squashing is useful for feature branches, but avoid squashing public shared history without agreement.<\/p><p>Many teams use squash merge in pull requests to keep main branch history clean.<\/p><h3>13. What is the use of git clean?<\/h3><p><strong>git clean<\/strong> removes untracked files from the working directory. It is useful when you want to clean files that Git is not tracking.<\/p><p>Example:<\/p><p>git clean -n<\/p><p>The <strong>-n<\/strong> option shows what would be removed without deleting anything.<\/p><p>To actually remove files:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git clean -f<\/p>\n<\/div><\/div><p>To remove untracked folders also:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git clean -fd<\/p>\n<\/div><\/div><p>Use cases:<\/p><ul>\n<li>Remove generated files<\/li>\n<li>Clean temporary files<\/li>\n<li>Reset project workspace<\/li>\n<li>Remove untracked build output<\/li>\n<\/ul><p>Be careful because git clean can permanently delete untracked files. Always preview with git clean -n before using force.<\/p><h3>14. How do you recover a deleted branch in Git?<\/h3><p>If a branch was deleted but its commits still exist, you can recover it using git reflog.<\/p><p>Steps:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git reflog<\/p>\n<\/div><\/div><p>Find the commit where the branch existed, then create a new branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout -b recovered-branch a1b2c3d<\/p>\n<\/div><\/div><p>If the branch was pushed to remote, you may also recover it from the remote if it still exists:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git fetch origin<\/p>\n<p>git checkout -b branch-name origin\/branch-name<\/p>\n<\/div><\/div><p>Branch recovery depends on whether the commits are still available.<\/p><p>This is a practical advanced Git scenario because accidental branch deletion can happen in real projects.<\/p><h3>15. How would you secure a Git repository?<\/h3><p>Git repository security is important because source code may contain business logic, credentials, and sensitive configuration.<\/p><p>Good practices:<\/p><ul>\n<li>Do not commit secrets<\/li>\n<li>Use <strong>.gitignore<\/strong> for <strong>.env<\/strong> files<\/li>\n<li>Enable branch protection<\/li>\n<li>Require pull request reviews<\/li>\n<li>Use signed commits if needed<\/li>\n<li>Restrict repository access<\/li>\n<li>Use SSH keys or tokens safely<\/li>\n<li>Rotate leaked credentials immediately<\/li>\n<li>Use secret scanning tools<\/li>\n<li>Avoid force push on protected branches<\/li>\n<\/ul><p>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.<\/p><p>Security should be part of Git workflow.<\/p><h3>16. What are signed commits?<\/h3><p>Signed commits use cryptographic signatures to verify that a commit was created by a trusted author. They help confirm commit authenticity.<\/p><p>Developers can sign commits using GPG or SSH signing.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git commit -S -m &ldquo;Add secure login&rdquo;<\/p>\n<\/div><\/div><p>Signed commits are useful in:<\/p><ul>\n<li>Open-source projects<\/li>\n<li>Enterprise repositories<\/li>\n<li>Security-sensitive systems<\/li>\n<li>Compliance-heavy teams<\/li>\n<\/ul><p>On platforms like GitHub, signed commits may show as &ldquo;Verified&rdquo;.<\/p><p>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.<\/p><h3>17. What is force push, and why is it risky?<\/h3><p>Force push overwrites the remote branch history with your local branch history.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git push &ndash;force<\/p>\n<\/div><\/div><p>It is risky because it can remove other developers&rsquo; commits from the remote branch if your local branch is outdated.<\/p><p>Safer option:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git push &ndash;force-with-lease<\/p>\n<\/div><\/div><p><strong>&ndash;force-with-lease<\/strong> checks whether the remote branch has changed before overwriting it.<\/p><p>Force push is sometimes used after rebasing a feature branch. It should not be used on shared branches like <strong>main<\/strong> or <strong>develop<\/strong> unless there is a clear reason and team agreement.<\/p><p>Branch protection can prevent accidental force pushes.<\/p><h3>18. How would you remove a sensitive file from Git history?<\/h3><p>If a sensitive file like<strong> .env<\/strong> or API key is committed, first rotate the exposed secret immediately. Then remove it from Git history using tools like <strong>git filter-repo<\/strong> or BFG Repo-Cleaner.<\/p><p>Basic approach:<\/p><ol>\n<li>Revoke or rotate the secret.<\/li>\n<li>Remove the file from history.<\/li>\n<li>Add the file to .gitignore.<\/li>\n<li>Force push cleaned history if required.<\/li>\n<li>Inform team to re-clone or clean local copies.<\/li>\n<\/ol><p>Deleting the file in a new commit is not enough because the secret remains in earlier commits.<\/p><h3>19. How does Git help automation testing teams?<\/h3><p>Git helps automation testing teams manage test scripts, framework code, test data, and CI\/CD integration.<\/p><p>Use cases:<\/p><ul>\n<li>Version control for Selenium scripts<\/li>\n<li>Branching for test framework changes<\/li>\n<li>Pull requests for test code review<\/li>\n<li>Tracking changes in test cases<\/li>\n<li>Running tests through CI pipelines<\/li>\n<li>Managing environment configuration safely<\/li>\n<li>Reverting unstable automation changes<\/li>\n<\/ul><p>Example:<\/p><p>An automation tester may create a branch to update login test scripts, push it to GitHub, and trigger Jenkins to run regression tests.<\/p><h3>20. How would you maintain a clean Git history in a large team?<\/h3><p>Maintaining clean Git history requires process, discipline, and tooling.<\/p><p>Good practices include:<\/p><ul>\n<li>Use meaningful commit messages<\/li>\n<li>Keep commits focused<\/li>\n<li>Avoid committing unrelated changes together<\/li>\n<li>Use pull requests<\/li>\n<li>Review before merging<\/li>\n<li>Squash noisy commits when appropriate<\/li>\n<li>Avoid force push on shared branches<\/li>\n<li>Delete merged feature branches<\/li>\n<li>Use branch naming conventions<\/li>\n<li>Protect main branches<\/li>\n<li>Use tags for releases<\/li>\n<\/ul><p>A clean history helps in debugging, rollback, release tracking, and code review.<\/p><p>For large teams, Git workflow should be documented clearly. Everyone should follow the same branching, commit, and merge rules to avoid confusion.<\/p><h2>Conceptual and Scenario-based Git Interview Questions<\/h2><p>These Git scenario based interview questions test how freshers think in real project situations.<\/p><p>The focus is on safe decision-making, team collaboration, mistake recovery, conflict handling, and practical Git usage in development, DevOps, and testing workflows.<\/p><h3>1. You committed changes to the wrong branch. What would you do?<\/h3><p>First, I would avoid panic and check whether the commit was already pushed. If it is only local, the fix is easier.<\/p><p>A common approach is to create a new branch from the current state:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout -b correct-branch<\/p>\n<\/div><\/div><p>Then go back to the wrong branch and remove the commit using reset if it was not pushed:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout wrong-branch<\/p>\n<p>git reset &ndash;hard HEAD~1<\/p>\n<\/div><\/div><p>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.<\/p><p>The correct solution depends on whether the commit is local or public.<\/p><h3>2. You pulled the latest code and got a merge conflict. How would you resolve it?<\/h3><p>I would first run git status to identify conflicted files. Then I would open each conflicted file and look for conflict markers.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD<\/p>\n<p>Current branch code<\/p>\n<p>=======<\/p>\n<p>Incoming code<\/p>\n<p>&gt;&gt;&gt;&gt;&gt;&gt;&gt; main<\/p>\n<\/div><\/div><p>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:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git add file-name<\/p>\n<p>git commit<\/p>\n<\/div><\/div><p>If the conflict is complex, I would talk to the developer who made the other change.<\/p><p>In real projects, conflict resolution should be tested before pushing.<\/p><h3>3. You accidentally deleted a file and committed the deletion. How can you recover it?<\/h3><p>If I know the commit where the file existed, I can restore it from that commit.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout HEAD~1 &mdash; src\/config.js<\/p>\n<\/div><\/div><p>Then I would commit the restored file:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git add src\/config.js<\/p>\n<p>git commit -m &ldquo;Restore config file&rdquo;<\/p>\n<\/div><\/div><p>If I do not know the exact commit, I would use:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git log &mdash; src\/config.js<\/p>\n<\/div><\/div><p>This shows the history of that file.<\/p><p>If the deletion was pushed, restoring with a new commit is safer than rewriting history.<\/p><p>This scenario tests whether the candidate understands Git history and file-level recovery.<\/p><h3>4. Your teammate force-pushed and your commits disappeared from the remote branch. What would you do?<\/h3><p>I would first check whether my local repository still has the commits. If yes, I can create a backup branch immediately.<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout -b backup-my-work<\/p>\n<\/div><\/div><p>Then I would check reflog:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git reflog<\/p>\n<\/div><\/div><p>If the commits are available, I can recover them using a new branch.<\/p><p>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.<\/p><p>For prevention, shared branches should have branch protection rules, and force push should be disabled on important branches.<\/p><h3>5. You need to work on an urgent bug, but your current feature work is incomplete. What will you do?<\/h3><p>I would use <strong>git stash<\/strong> to temporarily save my incomplete work.<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git stash<\/p>\n<\/div><\/div><p>Then I would switch to the required branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout main<\/p>\n<p>git checkout -b hotfix-login-error<\/p>\n<\/div><\/div><p>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:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git stash pop<\/p>\n<\/div><\/div><p>This approach avoids committing unfinished code just to switch branches.<\/p><p>It is a common real-world Git scenario because developers often need to pause feature work for urgent production or QA fixes.<\/p><h3>6. You pushed a commit containing an API key. What should you do?<\/h3><p>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.<\/p><p>Then I would remove the secret from the repository and add the file pattern to <strong>.gitignore<\/strong>.<\/p><p>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.<\/p><p>Important point: simply deleting the key in a new commit is not enough. Secrets in Git history must be treated as compromised.<\/p><h3>7. Your pull request has many unrelated changes. What would you do before review?<\/h3><p>I would clean the pull request before asking for review. First, I would check the changed files and separate unrelated changes.<\/p><p>Useful commands:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git diff<\/p>\n<p>git status<\/p>\n<p>git log &ndash;oneline<\/p>\n<\/div><\/div><p>If commits are messy but local, I can use interactive rebase to squash or edit them:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git rebase -i HEAD~5<\/p>\n<\/div><\/div><p>If unrelated file changes are present, I would remove or move them to another branch.<\/p><p>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.<\/p><h3>8. A release branch has a bug fix that is also needed in the main branch. What is the best approach?<\/h3><p>If only one specific bug-fix commit is needed, I would use git cherry-pick.<\/p><p>Example:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git checkout main<\/p>\n<p>git cherry-pick &lt;commit-id&gt;<\/p>\n<\/div><\/div><p>This applies only the selected commit to the main branch without merging the entire release branch.<\/p><p>Before cherry-picking, I would check whether the commit depends on other changes. If it does, cherry-picking may cause issues.<\/p><p>After cherry-picking, I would run tests and push the change through a pull request if the team follows review process.<\/p><p>Cherry-pick is useful for moving selected fixes across branches.<\/p><h3>9. Your local branch is behind the remote branch. What should you do before pushing?<\/h3><p>I would first fetch or pull the latest changes from the remote branch.<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git fetch origin<\/p>\n<p>git status<\/p>\n<\/div><\/div><p>If I need to update my branch:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git pull origin branch-name<\/p>\n<\/div><\/div><p>If the team uses rebase workflow:<\/p><div class=\"su-note\" style=\"border-color:#dddfde;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\"><div class=\"su-note-inner su-u-clearfix su-u-trim\" style=\"background-color:#f7f9f8;border-color:#ffffff;color:#333333;border-radius:3px;-moz-border-radius:3px;-webkit-border-radius:3px;\">\n<p>git pull &ndash;rebase origin branch-name<\/p>\n<\/div><\/div><p>After updating, I would resolve conflicts if any, run tests, and then push my changes.<\/p><p>Pushing without syncing may fail or create unnecessary conflicts. In team projects, keeping the local branch updated reduces integration problems and makes collaboration smoother.<\/p><p>This is a common Git workflow question for freshers.<\/p><h3>10. Your automation test branch has failing tests after merging the latest code. How would you debug it?<\/h3><p>I would first check whether the failure is due to test script changes, application code changes, environment configuration, or dependency updates.<\/p><p><strong>Steps:<\/strong><\/p><ul>\n<li>Run tests locally.<\/li>\n<li>Check merge changes using git diff.<\/li>\n<li>Review recent commits using git log.<\/li>\n<li>Identify whether locators, test data, or configuration changed.<\/li>\n<li>Compare with CI logs.<\/li>\n<li>Revert or fix only the faulty change.<\/li>\n<\/ul><p>If the failure started after a specific commit, git bisect can help find it.<\/p><p>For automation testing teams, Git history helps trace why a test started failing and whether the issue is in test code or application code.<\/p><h2>Best Ways to Prepare for Git Interviews<\/h2><ul>\n<li><strong>Learn Git Basics First:<\/strong> 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.<\/li>\n<li><strong>Practise Git Commands Hands-on:<\/strong> Do not just memorize commands. Create a local repository, add files, commit changes, create branches, merge them, and push the code to GitHub.<\/li>\n<li><strong>Understand Real Project Workflows:<\/strong> Learn how teams use Git in real projects through feature branches, pull requests, code reviews, merge conflicts, and release branches.<\/li>\n<li><strong>Practise Common Git Scenarios:<\/strong> Prepare for situations like undoing a commit, fixing merge conflicts, reverting changes, recovering deleted files, and syncing local code with remote repositories.<\/li>\n<li><strong><a href=\"https:\/\/www.placementpreparation.io\/blog\/github-profile-portfolio-guide\/\">Build a GitHub Portfolio<\/a>:<\/strong> Upload small projects, maintain proper README files, use meaningful commit messages, and show clean project structure. This helps in technical interviews and resume screening.<\/li>\n<li><strong>Use <a href=\"https:\/\/www.placementpreparation.io\/\">PlacementPreparation.io<\/a>:<\/strong> Practise Git MCQs, Git interview questions, <a href=\"https:\/\/www.placementpreparation.io\/mock-test\">mock tests<\/a>, technical questions, and placement-focused exercises to improve interview readiness.<\/li>\n<li><strong>Learn with GUVI and GUVI Zen Class:<\/strong> Use <a href=\"https:\/\/www.guvi.in\/courses\/it-and-software\/git-a-to-z\/?utm_source=placement_preparation&amp;utm_medium=blog_cta&amp;utm_campaign=git_interview_questions_for_freshers&amp;utm_content=start_your_journey\" target=\"_blank\" rel=\"noopener\">GUVI courses to learn Git<\/a>, <a href=\"https:\/\/www.guvi.in\/courses\/it-and-software\/github\/?utm_source=placement_preparation&amp;utm_medium=blog_cta&amp;utm_campaign=git_interview_questions_for_freshers&amp;utm_content=start_your_journey\" target=\"_blank\" rel=\"noopener\">GitHub<\/a>, <a href=\"https:\/\/www.guvi.in\/zen-class\/ai-software-development-course\/?utm_source=placement_preparation&amp;utm_medium=blog_cta&amp;utm_campaign=git_interview_questions_for_freshers&amp;utm_content=start_your_journey\" target=\"_blank\" rel=\"noopener\">software development<\/a>, <a href=\"https:\/\/www.guvi.in\/courses\/it-and-software\/fundamentals-of-devops\/?utm_source=placement_preparation&amp;utm_medium=blog_cta&amp;utm_campaign=git_interview_questions_for_freshers&amp;utm_content=start_your_journey\" target=\"_blank\" rel=\"noopener\">DevOps basics<\/a>, web development, and full-stack workflows in a structured way. You can also choose <a href=\"https:\/\/www.guvi.in\/zen-class\/\" target=\"_blank\" rel=\"noopener\">GUVI Zen Class<\/a> for mentor-led learning, hands-on projects, coding practice, and placement guidance.<\/li>\n<\/ul><h2>Final Words<\/h2><p>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.<\/p><p>Strong hands-on Git practice will help you answer Git interview questions confidently and work better in development teams.<\/p><h2>Frequently asked questions<\/h2><h3>1. What are the most commonly asked Git interview questions for freshers?<\/h3><p>Freshers are usually asked Git interview questions on basic commands, repositories, commits, branches, merge, rebase, pull, push, clone, staging area, and conflict resolution. Interviewers may also ask the difference between Git and GitHub, how to undo changes, and how to work with remote repositories.<\/p><h3>2. Is Git important for freshers in software development interviews?<\/h3><p>Yes, Git is important for freshers because most software teams use it for version control and collaboration. Even for entry-level roles, interviewers expect candidates to know basic Git commands, how to commit code, create branches, push changes, pull updates, and resolve simple merge conflicts.<\/p><h3>3. What Git commands should freshers learn before an interview?<\/h3><p>Freshers should learn commonly used Git commands such as git init, git clone, git status, git add, git commit, git push, git pull, git branch, git checkout, git merge, git log, and git reset. These commands are enough to answer most basic Git interview questions.<\/p><h3>4. What is the difference between Git and GitHub in interviews?<\/h3><p>Git is a version control system used to track code changes locally, while GitHub is a cloud-based platform used to host Git repositories and collaborate with other developers. In simple terms, Git manages the code history, and GitHub helps developers store, share, and review code online.<\/p><h3>5. How should freshers prepare for Git interview questions?<\/h3><p>Freshers should prepare Git interview questions by practicing basic commands on a real project. Create a repository, make commits, create branches, merge changes, push code to GitHub, and intentionally create a small merge conflict to understand how conflict resolution works. Practical knowledge helps answer Git questions confidently.<\/p><h3>6. Are Git interview questions asked in campus placements?<\/h3><p>Yes, Git interview questions are commonly asked in campus placements, especially for software developer, full-stack developer, DevOps, and backend developer roles. Companies may not ask very advanced Git questions from freshers, but they often check whether candidates understand version control, branching, commits, and basic collaboration workflows.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&rsquo;s Octoverse 2025 report, GitHub crossed 180 million developers and 630 million projects, showing [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":21969,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[45],"tags":[],"class_list":["post-21882","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming-interview-questions"],"_links":{"self":[{"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/posts\/21882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/comments?post=21882"}],"version-history":[{"count":11,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/posts\/21882\/revisions"}],"predecessor-version":[{"id":21971,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/posts\/21882\/revisions\/21971"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/media\/21969"}],"wp:attachment":[{"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/media?parent=21882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/categories?post=21882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.placementpreparation.io\/blog\/wp-json\/wp\/v2\/tags?post=21882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}