Almost every development team depends on Git for version control and seamless collaboration between team members. It’s the industry standard for tracking changes in any set of files. So if you’re pursuing a position on a dev team — from Software Developer to DevOps Engineer to Technical Writer — experience with Git will likely be a prerequisite for the job. And it’s more than likely that you’ll be asked questions to test your skills and knowledge of Git during your technical interview.
One of the best ways to prepare for an interview is to review commonly asked questions and practice answering them out loud. You can set up a mock interview with our AI-powered Interview Simulator and get practice responding to common interview questions. With the Interview Simulator, you can customize the circumstances based on the role and your experience, and try responding in writing or by speaking. All this practice will help you feel less nervous when the time comes to interview in front of your potential new employer.
Good to know: GitHub offers certifications that validate your skills with the platform. We recently revamped our course Learn Git & GitHub so it aligns with the GitHub Foundations Certification Program. The course also has new and improved detailed walkthroughs of GitHub’s mobile app, plus a new module on GitHub Actions and Codespaces. It’s another great way to get familiar with Git and GitHub before a job interview.
Here are 15 Git interview questions, along with tips on how to answer them, so you can start preparing for your upcoming interview.
Learn something new for free
1. What are branches, and what command creates a new branch?
C1 – – – C2 – – – C3
Above is an example of a simple commit history, in which C1 is the first commit (version), C2 is the second commit, and C3 is the third commit. This is an example of a master branch. Any new branches that get created are called the feature branch.
To create a new branch, you use the git branch <branch-name> command, and to view all the local branches, use the git branch command. The current branch is marked with an asterisk (*).
2. How often do you commit when using Git, and do you review files before committing?
You should be committing as frequently as possible. A good practice is to commit after every new feature as long as it can be done cleanly without breaking anything that already exists. Remember to leave a detailed message about your commit.
3. What are your best practices for writing commit messages?
For this question, the interviewer is looking to see if you’re consistent across your commit messages. You could talk about how you follow a template for each commit message within a project, which is one of the best practices for writing commits. It allows you to quickly identify and get some details about the commit without needing to do extra searching.
4. What’s the difference between git merge and git rebase? Which method do you prefer?
The two commands allow developers to incorporate changes from one branch into another. git merge allows for the creation of a new “merge commit” occurring between the master and feature commit. The command joins the two (or more if needed) together. For example, git merge will add changes to the current branch. Whereas git rebase can reapply the feature commit on top of the main branch.
So the major difference between the two is how the history gets managed. With git merge, the history of branches remains the same but can subsequently leave clutter from unnecessary old commits. And with git rebase, the main history is partially forfeited in favor of the feature history.
As for answering your technique preference, there’s no correct answer — just as long as you can prove your point. However, there’s some scrutiny with rebasing when working in large teams because you may inadvertently rewrite public commits. But both methods can be effective. Look into the “golden rule of rebasing” for more information.
5. What’s the difference between Git and GitHub?
While there are several differences between Git and GitHub, your interviewer is likely looking for you to point out that Git is a software focused on version control and code-sharing, whereas GitHub is a hosting service for Git repositories.
You can also discuss how Git is a command-line tool that’s installed locally on a system, and GitHub is a graphical user interface that’s hosted on the web. You can check out our article Getting Started with Git and GitHub Desktop to learn more key differences between Git and GitHub.
6. Do you use the command line with Git?
The command line is a text interface for the computer’s operating system. It’s a useful tool for developers to work with system files, among other tasks. Git can be used with graphical user interfaces (GUIs), like GitHub, or it can be used with the command line. All Git commands can run on the command line. However, this isn’t the case for GUIs. So even if you don’t know Git all that well, having proficiency with the command line is a good skill set to show interviewers that you have the capability to, at the very least, work with Git.
7. When should you use git push compared to when you use git pull?
git push is used to upload content from one repository to another. For example, you can push content from a local repository into a remote repository.
git pull is used to retrieve and integrate content from another repository. For example, you can pull content from a remote repository into a local repository.
8. What command do you use to return to a previous commit?
To return to a previous commit on a private, local repository, you’ll first want to run git log to pull up the branch’s history. Then, after identifying the version’s hash you want to go to, use the git reset command to change the repository to the commit.
For a public, remote repository, the git revert command is a safer option. It’ll create a new commit with the previous edits rather than delete commits from the history.
9. Has there ever been a time when you worked from multiple machines or with multiple developers? How did you like it? What did you find most challenging?
To answer this question, you can talk about your workflow. For example, explain how you’ve used Git in the past as your version control system for working between machines or sharing with multiple developers.
10. What methods do you use to clean up your feature branches?
For this question, you can mention these three commands.
git merge --squashis a command that can merge multiple commits of a branch.git commit --fixupmarks the commit as a fix of the previous commit.git rebase -i --autosquashis a rebase type of squash for merging multiple commits.
11. What are Git attributes used for?
Git attributes allow programmers to try different merge strategies within the files or directories of a project. Attributes are set on paths so that when certain settings are applied along the path, the attribute can perform requests. Git attributes can also perform requests when exporting your project.
12. Have you ever done debugging with Git? How did you do this?
To debug with Git, you use git bisect to identify the first commit to introduce a bug by using automatic binary search. And git blame identifies the author of a commit, while git grep searches for any string or regular expression in any of the files in the staging area.
13. Have you ever encountered a merge conflict? How did you go about resolving it?
Merge conflicts happen when there are competing changes within the commits, and Git is unable to automatically determine which changes to use. Merge conflicts can be resolved by editing the file that has the conflict. And once the edits get made, add and commit the file.
You can read more about merge conflicts in this GitHub article.
14. Explain Git hooks.
Git hooks are custom scripts that can run when certain actions occur. There are two types: client-side hooks and server-side hooks. Git hooks can be written in any scripting programming language. They should be located within the hooks subdirectory of the .git directory.
15. What’s your Git workflow like?
Some programmers use Git every day, while some don’t use it at all. It can depend on the project and team size, but you should be using Git just about every day that you program, in an ideal world. So modeling your workflow around Git is a great practice to have.
A best practice to follow regarding the VCS is to continuously communicate with team members to ensure everyone follows the same Git conventions.
More interviewing resources
If you need to refresh your Git skills more before your interview, check out our Learn Git & GitHub course. In this newly revamped course, you’ll review the most commonly used Git commands and be introduced to GitHub features that are helpful for teams and enterprises. You can also check out our blog on how to use GitHub in your resume.
For more interview prep, read our tips on answering technical and behavioral interview questions and check out this complete guide to acing the technical interview. Looking for more? Our Career Center has even more interview and job-hunting advice and tips, and be sure to check out our full course catalog if you’re looking to learn a new technical skill.
This blog was originally published in January 2023 and has been updated to include new details about Learn Git & GitHub course updates.