12 Interview Questions to Teach You How Git Works | HackerNoon

Version control systems, such as Git, are among the main technologies for a frontend developer. Learning the use of version control systems is very important in order to pass technical interviews. In this article, we will go over 12 interview questions on Git and their concise answers so that you can have a better idea about how Git works and be better prepared for your next interview.

1. What is Git, and what is it used for?

Git is a Distributed Version Control System that allows developers to track changes in code, enabling project development in an articulated manner. Git can be used for team collaboration, management of branches, creation of commits, and conflict resolution.

2. What is git-flow?

Git-flow is a branching model and workflow that solves the management of releases, features, and hotfixes in the project. The whole idea behind git-flow is to split the branches into the major branch master (or main) and a development branch develop, while other branches, if needed, must be created for features, releases, or bug fixing.

Key git-flow branches:

• Master (Main): the stable branch where the final releases go.
• Develop: current development server is here.
• Feature branches: new features are developed here.
• Release branches: Branches for preparing releases.
• Hotfix branches: Branches for critical bug fixes.

3. How does interaction with Git usually look like?

The usual interaction with Git goes through the following states:

1. Creating a new branch: this helps in isolating the work on a new feature (git branch or git checkout -b).
2. Modifying files: The code is modified, changes are staged inside staging area (git add).
3. Committing: saving changes with a descriptive message (git commit -m)
4. Pushing to remote: send changes to the remote repository (git push).
5. Pull from remote repository: sync your local repository with changes present in the remote (git pull).

4. What is a Staging area in Git?

This is an intermediary area in Git where all changed and added files with the git add command are placed before a commit. It’s like a “draft” of changes before they are saved officially. Accordingly, developers can add to this area only those files or lines of code that are prepared for a commit, excluding others if necessary.

5. What is the difference between git merge and git rebase?

Both git merge and git rebase are used to integrate changes from one branch into another, but they work differently:

Git merge: Creates a new merge commit that ties together the history of both branches. It preserves the branching history, showing where the codebase diverged and came back together.

git checkout feature-branch
git merge main

This will merge the changes from main into the feature-branch with a merge commit.

Git rebase: Rewrites the commit history by “moving” your branch on top of the latest commits from another branch, effectively linearizing the history.

git checkout feature-branch
git rebase main

This will replay your branch’s commits on top of main, avoiding the need for a merge commit.

Key difference: git merge preserves history and shows where branches diverge and come together, while git rebase creates a cleaner, linear history without merge commits.

6. What is git cherry-pick?

git cherry-pick– command that takes some existing commit and applies it to the current branch. It’s useful when you want to bring over just one commit, or a few, without merging an entire branch.

git cherry-pick <commit-hash>

This will apply the changes from the specified commit onto the current branch.

Cherry-picking is useful in cases where you need to apply a bug fix from one branch to another without merging all other changes that branch may contain.

7. Have you ever had to do anything unusual in Git?

This is an open-ended question. You can answer this based on your experience. Examples of less common tasks may include rewriting the commit history using git rebase, manually resolving tricky merge conflicts, recovering a deleted branch or commit, removing large files from repository history in order to reduce size.

8. How do you make Git forget about something?

There are several ways to make Git “forget” a file or directory:

1. Stop tracking a file: If a file was added to the repository, but you want Git to stop tracking it, use:

git rm --cached <file>

2. Remove a file from history in the repository: To completely remove a file from your history, you can use git filter-branch, git rebase, or tools such as BFG Repo-Cleaner.
3. Ignore the file in the future: Add the file to .gitignore to stop tracking it moving forward.

9. What are Conventional Commits and why do they exist?

Conventional Commits are standardized rules to create commit messages. Conventions keep the history of the changes made in the repository readable and straightforward. An adequately designed commit message puts context to these changes, whereby a teammate can start to understand not only what has changed but why and within what greater context the changes were committed. A popular convention is Conventional Commits. The format is as follows:

<type>(<scope>): <description>

Where:

• type: defines the type of commit, such as feat for new features, fix for bug fixes, and docs for changes in documentation.
• scope: an optional section that defines the specific area of the project where the change took place. Example areas include buttons or authentication.
• description: a short message about the change.

Example commit message:

feat(auth): add OAuth2 support

Advantages of commit conventions:

• They make it easier to read and follow changes made to a codebase.
• They tell you at a glance the nature of the changes: feature, fix, breaking change, etc.

10. How would you manage huge binary or frequently changing files within a Git repository?

Large binary files or files which frequently change are poorly handled by Git because Git is optimized to track changes in a very efficient manner on files. Below are some tactics to handle such kind of files:

1. Using .gitignore:

If the file doesn’t have to be under version control, it is better to first put it in .gitignore so Git won’t track it.

2. Git Large File Storage (Git LFS):

Git LFS is an extension to Git that replaces large files in your repository with lean references, while storing the large files separately on a server. This way, you can version large files without bloating the repository.

   git lfs install
   git lfs track "*.psd"
   git add .gitattributes

3. Repository Splitting:

If the repository becomes bloated with binary files, it may be better to split them into another repository. This will keep your code base light and easy to clone.

4. External Storage:

Store large assets elsewhere-in cloud storage, such as AWS S3-and link to them from within your repository, rather than committing them directly.

11. How do you undo the last commit but keep the changes in the working directory?

To revert to the last commit while still keeping the changes inside your working directory, execute the command below:

git reset --soft HEAD~1

12. What is a pull request, and how do you create one?

The Pull Request basically means to pull changes from one branch into another. This generally happens via some online platforms such as GitHub and GitLab. A PR involves code review, comments, and the opportunity for discussions before changes get merged into the main branch.

This includes some of the questions about the most important nuances of working with Git that may arise in an interview. Knowledge of Git is so important for a developer that it allows them to successfully cooperate with other developers, taking care of the project as a whole.

Make sure you know not only how the commands are spelled but also how they work in a real project.