Git Interview Questions and Answers Part 01

Using Git provides several advantages:

1. Supports teamwork by allowing multiple developers to collaborate on the same project simultaneously.
2. Each developer holds a full local copy of the repository, improving performance and enabling offline work.
3. Free, open-source, and widely supported across platforms.
4. Suitable for projects of all sizes and types.
5. Each repository contains a single .git directory managing the entire history.

Git usually handles merges automatically, but conflicts arise when:

• Two branches edit the same line of a file differently.
• One branch deletes a file that another branch has modified.

In such cases, Git cannot decide which change to keep and requires manual resolution.

Use git commit --amend to modify the most recent commit:

1. Make your changes to the files.
2. Stage them with git add.
3. Run the amend command:

git commit --amend

Git will open your default editor to update the commit message. Save and close to apply.

Note: Avoid amending commits that have already been pushed to a shared remote, as it rewrites history.

• Rename the current branch:

git branch -m <new_branch_name>

• Rename a different branch:

git branch -m <old_branch_name> <new_branch_name>

• Push the renamed branch to remote and update tracking:

git push origin -u <new_branch_name>
git push origin --delete <old_branch_name>

Using git fetch with manual merge:

git fetch origin
git log origin/main       # inspect incoming changes
git merge origin/main     # apply after review

Using git pull directly:

git pull origin main

Pull Requests (PRs) are a core part of collaborative development:

• Code Review: Team members can review code before it is merged, ensuring higher quality and catching bugs early.
• Collaboration: Developers can discuss, comment, and suggest changes within the PR itself.
• Version Control: Tracks proposed changes clearly and keeps the main branch stable.
• Accountability: Maintains a clear record of who approved and merged each change.

git stash temporarily saves uncommitted changes so you can switch context — such as moving to another branch — without losing your in-progress work. Stashed changes can be reapplied later.

Use git revert — it creates a new commit that undoes the changes, preserving history:

1. Switch to the target branch:

git checkout <branch_name>

2. Find the commit hash:

git log

3. Revert the commit:

git revert <commit-hash>

4. Git opens an editor to confirm the revert message. Save and close.

5. Push the revert commit:

git push origin <branch_name>

Why git revert over git reset? Revert is safe for shared repositories because it does not rewrite history.

HEAD is a special pointer in Git that always refers to the current position in the repository:

• Points to the latest commit on the currently checked-out branch.
• When you switch branches, HEAD automatically updates to the tip of the new branch.
• A detached HEAD state occurs when HEAD points directly to a specific commit instead of a branch — common when checking out a tag or old commit.

git tag -a creates an annotated tag, which stores additional metadata alongside the tag reference:

• Tagger’s name and email
• Date and time of tagging
• A custom descriptive message

Create an annotated tag:

git tag -a v1.0 -m "Version 1.0 Release"

Push the tag to remote:

git push origin v1.0

Annotated tags are preferred over lightweight tags for marking official releases because of their stored metadata.

1. Identify conflicting files:

git status

2. Open the conflicted file. Git marks conflicts like this:

Incoming changes

3. Manually edit the file to keep your changes, the incoming changes, or a combination of both. Remove all conflict markers.

4. Stage the resolved file:

git add <file>

5. Commit the merge:

git commit

6. If rebasing, continue with:

git rebase --continue

Rule of thumb: Use merge to preserve context in team workflows; use rebase to maintain a clean, readable history on feature branches.

git push origin --delete <branch_name>

To also remove the local tracking reference:

git fetch --prune

git cherry-pick applies changes from a specific commit to the current branch without merging the entire source branch.

Key use cases:

• Selective commit application: Pick only the commits you need.
• Bug fixes: Backport a specific fix to another branch (e.g., a release branch).
• No full branch merge required: Incorporate isolated changes cleanly.
• New commit: The picked changes are applied as a new commit on the current branch.

git cherry-pick <commit-hash>

A Git hook is a script that runs automatically at specific points in the Git workflow. They live inside .git/hooks/ and can be written in any scripting language.

Example — pre-commit hook to run ESLint:

#!/bin/sh
npx eslint . || exit 1

Make hooks executable:

chmod +x .git/hooks/pre-commit

For team-wide hooks, consider tools like Husky to version-control them alongside your project.

Use git reset with the appropriate flag depending on what you want to keep:

• Keep changes staged (soft reset):

git reset --soft HEAD~1

• Keep changes in working directory but unstaged (mixed reset — default):

git reset --mixed HEAD~1

• Discard all changes completely (hard reset):

git reset --hard HEAD~1

Use --hard with caution — changes are permanently lost unless recoverable via git reflog.

1. Start an interactive rebase for the last N commits:

git rebase -i HEAD~<number-of-commits>

2. In the editor, leave the first commit as pick and change subsequent ones to squash (or s):

pick   a1b2c3d  First commit message
squash e4f5g6h  Second commit message
squash i7j8k9l  Third commit message

3. Save and close. Git opens another editor to combine the commit messages — edit as needed and save.

4. Force-push if the branch was already pushed:

git push origin <branch_name> --force-with-lease

Use a soft reset to move HEAD back while leaving your files and staged changes intact:

git reset --soft <commit-hash>

Your commits are undone, but all the changes remain staged — ready to be re-committed or reorganized.

Combined usage — to fully clean a repository:

git reset --hard HEAD
git clean -fd

A file in Git moves through four primary states:

Full lifecycle example:

# Create a new file
touch feature.js

# Stage it
git add feature.js

# Commit it
git commit -m "Add feature.js"

# Modify it
vim feature.js

# Stage and commit the update
git add feature.js
git commit -m "Update feature.js"

Each git commit creates an immutable snapshot of all staged files at that point in time.

Git provides three reset modes, each with a different scope of impact:

Decision guide:

• Use --soft to re-commit with a different message or grouping.
• Use --mixed to unstage changes and re-evaluate what to commit.
• Use --hard only when you are certain you want to throw away all changes.

Git tags are named pointers to specific commits — most commonly used to mark release points (e.g., v1.0, v2.1). Unlike branches, tags do not move; they permanently reference an exact commit.

Types of tags:

Common tag commands:

git bisect uses binary search through commit history to efficiently pinpoint the commit that introduced a bug — without manually checking each one.

1. Start bisecting:

git bisect start

2. Mark the current (bad) commit:

git bisect bad

3. Mark a known good commit:

git bisect good <commit-hash>

4. Git checks out a commit halfway between. Test your code, then tell Git the result:

git bisect good   # if the bug is not present
git bisect bad    # if the bug is present

5. Repeat until Git identifies the exact commit that introduced the bug.

6. End the session:

git bisect reset

For large repositories, git bisect can find the culprit commit in O(log n) steps — dramatically faster than manual search.