24 Git Interview Questions For Developers

Git is a very popular version control tool in the software community. Git is a distributed version control system for tracking changes in source code. It is used by software developers to manage and share code repositories.

Git is also a popular tool for deploying web applications. To use Git effectively, you need to be familiar with its commands and workflows. Almost every fortune 500+ organizations use Git.

This contains basic to expert-level Git interview questions that an interviewer asks. These questionnaires will help to prepare for a job interview in a short time.

Often, these questions and concepts are used in everyday programming. But these are most helpful when an Interviewer is trying to test your deep knowledge of Git version control.

If you’re preparing for a job interview in which you’ll be asked to demonstrate your knowledge of Git, you’ll want to be prepared to answer some questions about it. Here are 24 Git interview questions that are commonly asked interviewing any developer working on Git.

Basics: Every Developer Should Know

Git is a Distributed Version Control System (DVCS) as well as it is a Source Code Management System (SCMS) which is used as a track that changes the file and also allows it to revert to any particular change.

Git uses a ” C ” programming language which ensures that the overhead of runtimes associated with high-level languages that reduced and make it fast. Also, it is open-source software distributed under the terms of the GNU ( General Public License ).

Git is used by software developers to manage changes to their source code. Git has become very popular in the past few years due to its many advantages over other systems such as Subversion (SVN).

Unlike SVN, Git is distributed, meaning that there is no central server containing all the source code repositories. This allows developers to work on the same project simultaneously from different locations without having to merge their changes.

Top 24 Git Interview Questions

Here is a list of well-sorted Git interview questions based on Git and its working:

Q1. Classify the version control system and its types.

Answer. Version Control System is the process management system that maintains the change records in the file or set of files over some time. And every change is maintained as a version. It is also called a Revision control system.

Features of VCS are:

• The version control system includes the tag system which helps to differentiate between alpha, beta, or various release versions for different documents.
• Up-to-date history is available for the document and file types.
• It doesn’t require any other repository system and it can be cloned as per the need and availability.

There are 3 types of the version control system are:

• Local Version Control System

It maintains the track of files within the local system and its approach is very basic and mild. This type is also error-prone which means that the chances of accidentally writing to the wrong file are high.

• Centralized Version Control Systems

In CVCS, all the changes in the files are tracked under the centralized server. It includes all the information on versioned files and a list of clients that check out files from that central place.

• Distributed Version Control System

This approach comes into the picture to overcome the drawback of the centralized version control system. The clients were able to completely clone the repository including its full history. If any server is not working properly the client repositories can be copied onto the server which helps to restore the files.

Q2. What are the advantages of using Git?

Answer. Advantages of using Git:

• Free and open-source
• Fast and small
• Secure
• Implicit backup
• Easier branching
• No need for powerful hardware

Q3. Name a few Git repository hosting services.

Answer. There are three main popular Git repository services-

1. GitLab
2. GitHub
3. Bitbucket

Q4. What is the Git life cycle?

Answer. The files in the Git project have various stages like creation, Modification, Refactoring, Deletion, and so on. Irrespective of whether this project is tracked by Git or not, these phases are still prevalent.

However, when a project is under the Git version control system, they are present in three major Git states in addition to these basic ones. Here are the three Git states:

• Working directory
• Staging area
• Git directory

These stages are the essence of Git. You get great flexibility in tracking the files due to these stages that files can reside in under Git.

Working Directory

• It considers a project residing in your local system, this project may or may not be tracked by Git. In this case, the project directory is called your working directory.
• Let’s assume that this directory is now tracked by Git. That is we’ve created a Git repository in this existing project directory, a hidden .git folder is initialized therein. In this state, Git is just aware of the files in the project. It won’t track the files yet. To track the files, you’ve to commit these files by first adding the files to the staging area.

This brings you to the next state in Git’s life cycle.

Staging Area

• While you’re in the working directory, you select the files that have to be tracked by Git. Why do you need this? Why don’t you track everything in the project? That’s because some files in the project like class files, log files, result-in files, and temporary data files are dynamically generated.
• It doesn’t make sense to track the versions of these files. Whereas the source code files, data files, configuration files, and other project artifacts contain the business logic of the application. These files are to be tracked by Git are thus need to be added to the staging area.

In other words, the staging area is the playground where your group, adds and organizes the files to be committed to Git for tracking their versions.

• It’s important to make a quick note of the term called indexing here. Indexing is the process of adding files to the staging area. In other words, the index constitutes files added to the staging area. This term will be explained again in the coming tutorial on Git terminologies.

Git Directory

• Now that the files to be committed are grouped and ready in the staging area, you can commit these files. So, you commit the group of files along with a commit message explaining what is about. Apart from the commit message, this step also records the author and time of the commit.
• Now, a snapshot of the files in the commit is recorded by Git. The information related to this commit (names of files committed, date and time of commit, author of commit, commit message) is stored in the Git directory.

Thus, the Git directory is the database where metadata about project files’ history will be tracked.

Q5. What do you understand by Git protocol?

Answer. Git protocol is a mechanism for transferring data in Git. But Git protocol does not support any authentication. So on plus side, this is a very fast network transfer protocol. But it lacks authentication.

Git can communicate using four protocols-

1. Local,
2. HTTP,
3. Secure Shell, and
4. Git.

• The local protocol uses when the remote repository is on the same disk but in a different directory and is generally used in cases where users share a common filesystem. The file-based repositories are easy to set up but not the easiest to set up when you want users to be able to work remotely.
• Secure Shell (SSH) is an authenticated protocol that comes with the advantage of being easy to set up, and efficient to read and write. It is easy to set up, and the connection is secure as the data transfer is encrypted.
• HyperText Transfer Protocol(HTTP)/ HyperText Transfer Protocol Secured (HTTPS) is probably the simplest protocol to set up. It is also not resource-intensive for the server. Once the repository is placed under a web server, all the users who can access the server have access to the repository. However, there will be a considerable amount of network overhead, and cloning might take longer.
  
• Git protocol is available with Git and is one of the fastest protocols. However, it lacks robust authentication features and is generally suitable to offer read-only access to public projects. It is not uncommon to pair it with SSH for specific users who need to write access. It listens on a dedicated port 9418 which provides services similar to the SSH protocol.

Q6. What is “git commit -a”?

Answer. “git commit -a” is used to write a commit message in Git. The -a is to instruct the git to commit the new content of all tracked files that have been modified.

If any new file needs to be committed for the first time, “git add<file>” is used before git commit.

Q7. Define conflict in git. How you can solve a conflict in git?

Answer. A conflict in Git arises when the commit needs to be merged in one file, and also the current commit has changed in the same place in that file. And in this case, It is not able to predict which change should take precedence.

For solving any conflict in Git, we need to edit the files for fixing the conflicting changes and then we need to run git add command to add the resolved files.

After that git commit the command that needs to be run to commit the repaired merge.

Q8. What are the advantages of git over SVN?

Answer. The differences between Git and SVN are:

Q9. Why does a developer need branching in git? How to create a new branch in git?

Answer. Branching is used to create a new own branch till some commit and then can easily switch between those branches. Git allows the developers to have multiple local branches that can be entirely independent of each other. This will help the developers to go to their previous work keeping the recent work intact.

Use the following command to create a new branch in GIT:
$/> git checkout –b <branchname>

Q10. Difference between “git merge” and git rebase”? And when do you use git rebase instead of git merge?

Answer. Rebasing and merging are the two most popular ways of applying changes from one branch to another. They both give similar results in the end but work differently.

In Git, the rebase command integrates changes from one branch into another. As well as it is an alternative to the better-known merge command. Most visibly rebase differs from merge by rewriting the commit’s history, to produce a straight, linear succession of commits.

Merging is a way of putting forked history back again. The Git merge command lets the developers take the independent lines of development created by the Git branch and integrate them into a single branch.

With rebase you say to use another branch as the new base for your work.

when to use git rebase instead of git merge:

1. If you have any doubts, use Git merge.
2. The choice for Git rebates or merging is based on what you want your history to look like.

Q11. Suppose you have to remove a file from git without removing it from your file system. How can you do it?

Answer. Syntax:

git reset filename

Q12. Explain the git-flow workflow.

Answer. Gitflow workflow employs two parallel long-running branches to record the history of the project, master, and develop:

• Hotfix –
  
  Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they’re based on master instead of developing.
• Master –
  
  It is always ready to be released on LIVE, with everything fully tested and approved (production-ready).
• Develop –
  
  It is the branch to which all feature branches are merged and where all tests are performed. Only when everything’s been thoroughly checked and fixed it can be merged to the master.
• Feature –
  
  Each new feature should reside in its branch, which can be pushed to the developed branch as its parent one.

Q13. What do you mean by git fork? Explain the advantage of forking workflow.

Answer. A fork is a remote, server-side copy of a repository, distinct from the original. A fork isn’t a Git concept really, it’s more a political/social idea.

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository which leads to a clean project history. Developers push to their server-side repositories, and only the project maintainer can push to the official repository.

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

Answer. The difference between git fetch and git pull.

Q15. What is git stash? Is it possible to create multiple stashes in Git?

Answer. Git stash is temporary shelves or stashes that help you with the changes that you have made to your working copy so you can work on another project also, and then come back and re-apply it later on.

The Git stash will take the working directory in its current state and index it to put it on the stack at a later stage so that what you get is a clean working directory. This means that if you are in the middle of some task and need to get a clean working directory and together you want to keep all your current edits then you can use the Git stash.

Yes. You can run git stash several times to create multiple stashes, and then use the git stash list to view them.

Q 16. Explain the git revert command.

Answer. The git revert command is a forward-moving undo operation that offers a safe method of undoing changes. Instead of deleting or orphaning commits in the commit history, a revert will create a new commit that inverses the changes specified. Git revert is a safer alternative to git reset in regards to losing work.

Q17. What is a commit message? How do you fix a broken commit?

Answer. A commit message is a comment that we add to a commit. We can provide meaningful information about the reason for committing by using a commit message. In most organizations, it is mandatory to put a commit message along with each commit. Often, commit messages to contain JIRA tickets, bug IDs, defect IDs, etc. for a project.

To fix any broken commit, you will use the command git commit—amend. By running this command, you can fix the broken commit message in the editor.

Q18. Explain the term sub-git and how it is useful in your project.

Answer. SubGit is a tool that is used for a smooth, stress-free SVN to GIT migration. It is a solution for a company-wide migration from SVN to GIT.

It the widely used for the following reasons:

• It is much better than git-SVN.
• There is no requirement to change the infrastructure that is already placed.
• Allows using all features of Git and SVN.
• It provides a genuine stress-free migration experience.

Q19. Why git better than subversion?

Answer. Git is decentralized, so all your local copy acts as a repository to compare and keep in view, while the remote repository is inaccessible. Whereas the subversion is centralized so that the repository can get offline and affect the work. That’s why developers found Git better than Subversion.

Q20. Difference between pre-receive, update, and post-receive hooks in git?

Answer. The pre-receive hook is invoked when a commit is pushed to a destination repository. Any script attached to this hook is executed before updating any reference. This is mainly used to enforce the development of best practices and policies.

An update hook is similar to a pre-receive hook. It is triggered just before any updates are done. This hook is invoked once for every commit that is pushed to a destination repository.

Post-receive hook is invoked after the updates have been done and accepted by a destination repository. This is mainly used to configure deployment scripts. It can also invoke Continuous Integration (CI) systems and send notification emails to relevant parties of a repository.

Q21. Do you differentiate between Head, working tree, and index?

Answer. Differentiate between:

HEAD: It is a reference to the last commit in the currently checked-out branch.

Working Tree: It is the directory tree of sources and files that you edit and see. Also known as a workspace and working directory.

Index: This is the single, large, as well as binary file in <baseOfRepo>/.git.index , which lists all the files in the current branch.

Q22. What are the various branching strategies for a developer in git?

Answer. Various branching strategies are as follows:

•Feature Branching:

A feature branch keeps all the changes for a particular feature inside a branch. When the feature is fully tested and validated, then it is merged into the master.

•Task Branching:

In Task branching, each task is implemented on its branch with the task key included in the branch name. With this, it is easy to see which code implements which task, just need to find the task key in the branch name.

•Release Branching:

We can clone a branch to form a release branch once the development branch has acquired enough features for a release. Creating the release branch starts the next release cycle, and hence no new feature can be added after this point, only bug fixes are allowed.

Q23. The major difference between Git and GitHub.

Answer. Git v/s GitHub.

Q24 Describes the function of “Git Clone” and “Git config”?

Answer. Git Clone: It is a command which creates a copy of an existing Git repository, and gets a copy of a central repository. Cloning is the most common way used by programmers to secure their projects.

Git config: It is a command that convenient way to set configuration options for your Git installation. The behavior of a repository, user info, preferences, etc. can be defined through this command.

In A Nutshell…

As a developer, it’s important to be familiar with Git and all of its features. If you’re looking for a new job, you’ll likely be interviewed about your Git skills.

In this article, we’ve compiled a list of 24 Git interview questions that you should make sure you study for. Many different questions can be asked in a Git interview.

We’ve collected the most common questions and provided answers and tips for you to study. Do you have any questions about Git? Let us know in the comments below.

FAQ's