Almost every company out there uses Version Controlling System for managing projects and thus, they definitely ask related technical questions for Git in their interviews. This article will cover the most frequently asked Git interview questions to help you with your interview.
Git is a free and open-source distributed version control system designed to handle small to large projects with speed and efficiency. It is the most widely used tool among developers around the world to build and contribute all types of projects. Git is simple to learn and has a tiny footprint with lightning-fast performance.
Table of Contents
Q1. What is Git?
Git is free of cost open-source platform of a distributed version control system designed to handle everything from small to extensive projects with speed and efficiency. Git is software for tracking changes in any set of files, usually used to collaboratively coordinate work among programmers developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows.
Q2. What are branches in Git?
As multiple developers work parallel on a project, they create their local repository, making various changes in a single commit. However, in Git, branches manage several separations, and once finished the work in a branch, they will merge it with the master branch.
Q3. What is a repository?
A Git repository is a place that contains a collection of files/sub-directories of different types of a Project. Git stores these files/sub-directories either on the local repository or the remote repository.
Q4. What is a "bare repository”?
A bare repository is the same as other default repositories but one cannot make commits in a bare repository. A bare repository cannot track the project’s changes as it does not have a working tree. A working tree is a directory/folder in which all the project files/sub-directories reside. A bare repository is a .git folder with a selected folder where all the project files/sub-directories reside.
Practically speaking, everything in the repository apart from .git is a part of the working tree.
Q5. What is a “non-bare repository”?
A non-bare is also called a default git repository. It has a .git folder, the repository’s backbone, where all the essential files for tracking the folders’ changes are stored. It stores the hashes of commits made in the branches and a file where the hash of the latest commit is stored.
Q6. What is a conflict in Git?
A conflict is an event that occurs when Git is unable to resolve differences in code between two commits automatically.
A conflict occurs when two separate branches have made changes to the same line in a file or when a file has been removed in one branch but edited in the other branch. Conflicts will most likely happen when people working in a team. There are many tools to assist resolve merge conflicts.
Q7. What is Stash in Git?
We can describe the Stash operation as a “clipboard” for uncommitted local changes. Putting your local modifications on the Stash will result in a clean working copy, i.e., you’ve got no more local changes.
Such a “clean working copy” state is a necessary prerequisite for several actions in Git: i.e., before switching branches, pulling from a remote, or merging changes, you should always ensure to process a clean working copy without any local changes.
Changes that the user stored on the Stash can be restored later in your working copy, at any time. You can create Stashes how much you want; the user has no limits to storing only a single set of changes.
Q8. How can the user undo a commit that has been pushed already to a shared branch on a remote repository?
First of all, using git push –force wouldn’t be the right solution in most cases. It is because force push has the potential to overwrite other’s work or at least suddenly change their commit history.
A better, secure approach would be to use git revert because this cannot rewrite/manipulate old commit history; instead, creates a new commit that corrects the effects of the unwanted one(s).
Q9. You have deleted a branch accidentally. Is there any way to recover it?
Using the git reflog command, you can inspect all of the recent HEAD pointer movements in this repository. If the deletion has not been too long ago, you can find the previous commit on this branch. Using that commit’s SHA-1 hash, you will be able to re-create the branch.
Q10. What is rebase in Git?
Rebasing is a process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow.
Q11. What is mean by “long-running” or “long-lived” branches in Git?
Technically, all branches in Git work identically. Conceptually, however, many teams create a distinction between “long-running” and “short-lived” branches.
Long-running branches are mean to stay in the repository during their complete lifetime. They are typically shared among the whole team and are being merged into other branches, short-lived branches.
Those short-lived branches are typically associated with feature development or bugfixes. When the work on these branches is complete, they’re merged into a long-running branch and then deleted.
Q12. What are Submodules in Git?
Git submodules allow keeping a git repository as a sub-directory of another git repository. Git submodules are merely relevant to another repository at a specific snapshot in time. Git submodules enable a Git repository to include and track the version history of external code.
Q13. How are you able to - with the assistance of Git - run a sanity check on code before it is committed to the repository?
Git offers a mechanics named “hooks.” These are custom scripts that will be configured to be run when certain events happen. To answer this question, it would make sense to write a “pre-commit” hook: before a commit is finalized, this hook is triggered and runs automatically. The script can be fully custom and, for instance, check code to be compliant with agreed-upon coding standards.
Q14. Is it possible to change an old commit’s message, although newer commits have already been created?
If the commit in question is the very last commit, a simple solution would be to use the –amend flag of git commit. However, since other commits are created afterward, amending is not an option. In such a case, to manipulate old commits – including their commit messages can use Git’s “interactive rebase” tool.
Q15. What is mean by “rewrite commit history”? Give some instances of when this can happen in Git.
Commit history is “rewritten” when existing commits are manipulated after the fact. The most important effect of this can be that the manipulated commits will receive new SHA-1 hashes, making them utterly unique commit objects from Git’s perspective. It’s especially dangerous if others on a team have already based their work on this old commit history; if it’s manipulated after the very fact, this can cause problems.
Commit history is “rewritten,” i.e., during a rebase, interactive rebase, or amending the very last commit.
Q16. Why is it demoralize to us "git push --force"? What are some of the potential downsides?
The only problem with –force is that it changes history in an upstream repository, and someone may have made changes to the state of the repository before history was changed. It causes problems – and is why it is not a recommended solution.
Q17. You committed on the “master” branch instead of “feature/login” accidentally. Describe the process of correcting this mistake.
First, you should check the “feature/login” branch. There, copy the required commit overusing the Git cherry-pick command. Then, check “master” again and use Git reset –hard HEAD~1 to undo the (on this branch) unwanted commit.
Q18. You committed a file and only after some time noticed that it actually should have been “ignored.” How can you solve this?
Git ignores “untracked” files (these are files that haven’t yet been committed to the repository) only. If a file was inadvertently committed to the repository and shall then be ignored, you’ve to first untrack it; the user can do this, i.e., by moving it out of the repository temporarily, so Git examines it “deleted.” After confirming this “deletion” in a fresh commit, you can then move the file back and add it to the project’s .gitignore list.
Q19. How can the user restore a previous version of your project?
The git reset command is used for this task: you can provide the SHA-1 hash of the commit the user wants to go back to and thereby restore the project to that revision’s state.
Q20. Differentiate between “fetch” and “pull.”
Git fetch only downloads unique data from a remote repository – but it does not combine new data into your working files. Fetch is great for getting a unique view of all the things that happened in a remote repository.
Git pull, in contrast, not only downloads new data; it also directly combines it into your current working copy files. You can think of pull as a combination of fetch and merge (or rebase).
Q21. Git is a so-called “distributed” version control system. What’s the difference to a “centralized” one?
Subversion is an example of a CVCS (centralized version control system): all team members work towards a single central repository placed on a remote server. A “checkout” from this central repository will place a “working copy” on the user’s device. It is a snapshot from a particular version of the project on his disk.
In Git, a DVCS (distributed version control system), things work a bit differently. Rather than a “checkout,” a Git user will “clone” a repository from a remote server. In return, the user receives a full-fledged repository, not only a working copy. The user then has their repository on their local machine – including all of the project’s history. You can do everything on your local device: commit, inspect the record, restore older revisions, etc. Only if you wish to share your work with the world will you connect to a remote server.
Q22. What is commit?
Git creates the commit as and when a developer saves any unique work. Commit is a screenshot of all files/sub-directories, and Git will use the previously used file if a file isn’t changed from one commit to another. One commit creates a sequence to other commits and forms a development history graph. Unique cryptocurrency hash identifies the commit in Git.
Q23. Are Git and GitHub the same thing?
Git and GitHub are connected like Github is a service to use Git, Service for projects that use Git for version control.
Git is a software tool to use a version control system. Tool for projects that want to develop software collaboratively.
Q24. How to deal with large binary files in Git?
To handle large binary files is a significant problem in Git, and to handle this problem “Huge File Storage” extension works well for Git. Install LFS on your local device, and after this, it will not store your large files in the local repository. Instead, it will keep it in a dedicated LFS cache and store.
Q25. What do you mean by “git cherry-pick”?
If accidentally you have created a change into the wrong branch, you can use the command “git cherry-pick.” This command will permit you to apply to commit from one branch to another branch.
Q26. When to use the “git cherry-pick” command?
Git cherry-pick command can sometimes end in duplicate commits, and thus, it must cautiously use it. The below-given situations are apt if forethought to use the Git cherry-pick command:
- When you accidentally make a commit in the wrong branch.
- When you want to make changes, other team members propose.
Q27. Why developers use Git Clone?
Developers prefer cloning as it is the easiest way to get a copy of the central repository. The ‘git clone’ command helps in creating a copy of the current Git repository.
Q28. Why do you use SubGit?
The SubGit is a famous tool used for stress-free transferring of SVN to Git, and it allows using various Git and sub-version features.
Q29. Differentiate between HEAD, working tree, and index.
The working tree, also known as the active directory or workspace, is the source files’ directory tree. Whereas the index, also known as the staging area, lists all the current branch files. HEAD is known as the last commit in the checkout branch, which was marked.
Q30. What are the benefits of using the Version Control System (VCS)?
- All members of the team can work on any file at any time without any restrictions.
- Allow us to estimate files, recognize differences, and merge the changes into a standard version.
- Keep track of application builds by determining which version is nowadays in development, QA, and production.
- Allows all team members to have complete knowledge of the project.
Q31. What is a “detached HEAD” in Git? Why is it considered a “dangerous” state?
Almost always, when you check a revision in your repository, you do this by mentioning a branch’s name: you tell Git to create this branch your current HEAD branch. However, instead of checking a branch, you can also choose to check a particular commit or tag.
By doing this, you’ve put your local repository in a “Detached HEAD” state: the HEAD pointer is not on a branch but a particular revision.
If you make additional commits in this state, they will not be related to any branch (since no branch is currently checked out). In such a scenario, it’s straightforward to lose new commits.
Q32. For what purpose the Git Stash Drop and Git Stash Clear commands are used?
Git Stash Drop command or is used to delete a specific stash that is not necessary.
Git stash clear command is applied when all the stashes are removed in one go from the repository.
Q33. Explain Git Hooks.
Git hooks are easy scripts that run before or after particular actions, like commit, push, update, or receive. They’re comprised of shell scripts that are activated after you run the corresponding Git commands. Git Hooks are useful in many tasks, like client-side validation.
Q34. Differentiate between Git stash apply and Git stash pop.
The commands ‘Git stash apply’ and ‘Git stash pop’ are used when the user has to re-apply the stashed changes and start working from where you left.
The difference between ‘Git stash pop’ and ‘Git stash apply’ is that while the ‘Git stash apply’ command keeps the stash list changes for future use, the ‘Git stash pop’ command deletes the modifications from the Stash after applying it.
Q35. How can the user know if a branch has already been merged or not?
There are two commands to see these two things.
- Git branch –merged – This command provides a list of branches that are merged into this branch.
- Git branch –no-merged – This command provides a list of branches that haven’t been merged.
Q36. What’s the difference between reverting and resetting?
The revert command is used to form a new commit that undoes the changes made in the previous commit. Added a new history to the project; the present history isn’t modified.
Git reset command is used to undo the local changes that have been made into a Git repository. Git reset operates on commit history, the staging index, and also the working directory.
Q37. If you recover a removed branch, what work is returned?
The sub-directories that were stashed and saved in the Stash’s index can be recovered. Will lose the untracked files. That is why it’s a good idea to stage and commit your work or stash them.
Q38. 'git remote' is different from 'git clone.' How?
‘git remote’ enables you to create, view, and delete connections to other repositories. It is used to remit to a remote repository or a central repository.
‘git clone’ enables you to make a clone or copy of the target repository. It’s used to target a different existing repository.
Q39. What command is used to fix a broken commit?
“git commit –amend” command is used to fix a broken commit in Git, which helps you merge the staged changes with the previous commits instead of creating an entirely new commit.
Q40. Differentiate between Git merge, and Git rebase?
To include new commits into your feature branch, you use Git merge.
- Creates an additional merge commit every time you need to include changes
- Pollutes your feature branch history
As another to merging, you can rebase the feature branch into master.
- Incorporates all the new commits within the master branch
Rewrites the project history by creating different commits for every commit in the original branch
Q41. Differentiate between fork, branch, and clone?
The fork is the procedure when a copy of the repository is created. It’s usually experimentation within the project without affecting the initial project. These are used to advise changes or take inspiration from someone else’s project.
Git branches refer to separate projects within a git repository. If several branches are in a repository, then each branch can have entirely different files and folders.
Git clone refers to making a clone or a duplicate of an existing Git repository in a new directory. Cloning automatically makes a connection that points back to the initial repository, making it very easy to interact with the central repository.
Q42. How do you find the list of files or sub-directories that has been changed in a specific commit?
The command to find the list of files that has been changed in a specific commit is:
git diff-tree –r {commit hash}
- -r flag allows the command to list separate files
- commit hash lists all the files that were changed or added in the commit.
Q43. What does the 'Git reset --mixed' and 'git merge --abort' commands do?
‘Git reset –mixed’ command is used to undo changes made in the working directory and staging area.
‘Git merge –abort’ command helps stop the merge process and return to the state before merging.
Q44. A bare repository is different from the standard way of initializing a Git repository. How?
Using a standard way:
- The user creates a working directory by executing the ‘git init’ command.
- A .git subfolder is created with all git-related change history.
Using a bare way:
- It doesn’t contain any working or checked-out copy of source files.
- Bare repositories contain git revision history in the root folder of your repository instead of the .git subfolder.
Q45. Which language is used in Git?
C language is used in Git.
Git is a fast and reliable control system, and the language that makes this possible is ‘C.’
Using C language reduces the overhead of running times, which are common in high-level languages.
Q46. What are the advantages of using Git?
- Faster release cycles
- Easy team collaboration
- Widespread acceptance
- Maintains the integrity of source code
- Pull requests
Q47. Name some Git commands with their purpose.
- ‘Git config’ Configure the username and email address.
- ‘Git add’ Add one or more files to the staging area.
- ‘Git diff’ View the changes made to the file.
- ‘Git init’ Initialize an empty Git repository.
- ‘Git commit’ Commit changes to head but not to the remote repository.
Q48. How is the commit command executed?
The commit command is executed after the files to be committed have been added to the staging area using the Git add command.
Q49. Name some of the famous Git hosting repositories.
- GitHub
- GitLab
- BitBucket
- Beanstalk
- FogBugz
- Surround SCM
- Buddy
Q50. What is the method to revert a commit that has already been pushed and made public?
Following are the methods through which you can revert a commit:
- Delete or fix the bad file in a new commit and push it to the remote repository.
- Write a new commit to undo all the changes that were made in the bad commit.
Conclusion
In this article, we have covered most of the technical questions asked in interviews regarding Git. We hope that by having an insight over them will help you face the technical aspects of any interview with grace. Keep calm, be confident and stay positive during your interview because understanding technical concepts isn’t the only thing; your presentation also matters.
