Git Interview Questions For Developers

Tags: git, devops, career
Published: 2019-11-07 06:13:45

Git is a very popular version control tool in the software community. Almost every fortune 500+ organizations use Git. This contains basic to expert level Git interview questions that an interviewer definitely 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.

Basics: Every Developer Should Know

Original author (Developer)	Linus Torvalds
Released on	7 April 2005
Stable release	2.23.0 / 16 August 2019
Languages used in	C, Shell, Perl, Tcl, Python
Operating system	Windows, Linux, macOS
Type	Version control
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 also allows to revert back to any particular change.

Git uses ” C “ <a href="https://codersera.com/blog/?s=programming+language">programming language</a> 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 ).



<h1>Classify the version control system and its types?</h1>

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

<h1>Features of VCS are</h1>

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:

<h2>Local Version Control System</h2>
It maintains the track of files within the local system and its approaches is very basic and mild. This type is also error-prone which means that the chances of accidentally writing to the wrong file is high.


<h2>Centralized Version Control Systems</h2>
In CVCS, all the changes in the files are tracked under the centralized server. It includes all the information of versioned files and a list of clients that check out files from that central place.


<h2>Distributed Version Control System</h2>
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 on to the server which helps to restore the files.



<h1>What are the advantages of using Git</h1>

<h2>Advantages of using Git</h2>

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

<h1>Name a few Git repository hosting services.</h1>

<h2>There are three main popular Git repository services</h2>

GitLab
GitHub
Bitbucket

<h1>What is the Git life cycle?</h1>

Answer. The files in the Git project have various stages like creation, Modification, Refactoring, and 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 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. 

<h2>Working Directory</h2>

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 as 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 life-cycle.

<h2>Staging Area</h2>

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 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 needs to be added to the staging area.

In other words, the staging area is the playground where you group, add and organize 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, index constitutes of files added to the staging area. This term will be explained again in the coming tutorial on Git terminologies. 

<h2>Git Directory</h2>

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 the 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. 

<h1>What do you understand by Git protocol?</h1>

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-

, 
Secure Shell, and
Git.
<h2>Local</h2>
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.
<h2>Secure shell</h2>
Secure Shell (SSH) is an authenticated protocol which comes with the advantage of being easy to set up, efficient read and write. It is easy to set up, and the connection is secure as the data transfer is encrypted.
<h2>HTTP</h2>
HyperText Transfer Protocol(HTTP)/ HyperText Transfer Protocol Secured (HTTPS) is probably the simplest protocols 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.
<h2>Git</h2>
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

<h1> What is “git commit -a” </h1>

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.

<h1> Define conflict in git? How you can solve a conflict in git?</h1>

Answer. A conflict in Git arises when the commit that 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 a command to add the resolved files.

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

<h1>What are the advantages of git over SVN?</h1>

The differences between Git and SVN are:

Git	SVN
Git is a decentralized version control tool.	SVN is a centralized version control tool.
The entire repository can be cloned
on the local system.	Version history is stored on a server-side
repository.
Commits are possible even if offline.	Only online commits are allowed.
The work is shared automatically on commit.	The work is not shared automatically.
Push/Pull operations are faster in Git	Operations are slow.

<h1> Why a developer need branching in git? How to create a new branch in git?</h1>

Answer. Branching is used to create a new own branch till some commits and then can easily switch between those branches. Git allows the <a href="https://codersera.com/">developers</a> to have multiple local branches that can be entirely independent of each other. This will definitely 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>

<h1>Difference between “git merge” and git rebase”? And when do you use git rebase instead of git merge?</h1>
Answer. Rebasing and merging are the two most popular ways of applying changes from one branch into another one. They both give similar results at 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, in order to produce a straight, linear succession of commits.

Merging is the way of putting forked history back again. The Git merge command to let 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:

<ul><li>If you have any doubt, use Git merge.</li>
<li>The choice for Git rebase or merge based on what you want your history to look like.</li></ul>