36 Git Interview Questions and Answers

Git is a distributed version control system that helps developers track changes in source code during software development. It enables collaboration, allows multiple people to work on the same project, and helps manage code history, branching, and merging.

Unlike centralized systems such as SVN or CVS, Git is distributed, meaning every developer has a full copy of the repository history. This allows for faster operations, offline work, and more robust branching and merging capabilities.

A Git repository is a storage space for your project, including all files and their history. You can create a new repository by running 'git init' in your project directory, which initializes a new, empty repository.

'git add' stages changes to be included in the next commit, while 'git commit' records those staged changes in the repository's history. This two-step process allows you to review and group changes before saving them permanently.

You can use the 'git status' command to see which files have been modified, which are staged for commit, and which are untracked. This helps you keep track of your work before committing changes.

A Git branch is a separate line of development, allowing you to work on new features or bug fixes without affecting the main codebase. Branches make it easy to experiment and collaborate without disrupting the main project.

You can use the 'git merge' command to combine changes from one branch into another. This is commonly used to integrate feature branches back into the main branch after development is complete.

A merge conflict occurs when changes in different branches affect the same part of a file. Git will mark the conflict, and you must manually edit the file to resolve the differences before completing the merge.

The 'git log' command displays a list of commits, showing information such as commit IDs, authors, dates, and messages. This helps you track changes and understand the evolution of the project.

A 'detached HEAD' state occurs when you check out a specific commit instead of a branch, meaning HEAD points directly to a commit. You might encounter this when reviewing old commits or testing changes. To return to a normal state, check out a branch using 'git checkout branch_name'. If you made changes you want to keep, create a new branch from the detached HEAD before switching.

Git tracks content, not file names, so it detects renames and moves based on similarity of file content. There is no explicit command to record a rename; instead, Git infers it during 'git diff' or 'git log' operations. However, using 'git mv' helps stage the move and makes it easier for Git to detect the change.

'git merge' combines two branches, preserving the history of both, while 'git rebase' moves or reapplies commits from one branch onto another, creating a linear history. Use 'merge' to preserve context and collaboration history, and 'rebase' to simplify history before integrating changes, especially for feature branches.

'git stash' temporarily shelves changes in your working directory that are not ready to be committed, allowing you to switch branches or pull updates without losing your work. For example, if you are working on a feature and need to quickly fix a bug on another branch, you can stash your changes, switch branches, and then reapply the stash later.

First, fetch the latest changes using 'git fetch'. Then, you can either merge the remote branch into your local branch with 'git merge origin/branch_name', or rebase your changes onto the updated remote branch with 'git rebase origin/branch_name'. Resolve any conflicts that arise, then push your changes.

'git cherry-pick' applies the changes from a specific commit onto your current branch. This is useful when you want to selectively apply bug fixes or features from one branch to another without merging the entire branch.

Git hooks are scripts that run automatically at certain points in the Git workflow, such as before committing or after merging. They can be used to enforce code standards, run tests, or automate deployment steps. Hooks are stored in the '.git/hooks' directory and can be customized for project needs.

To undo a pushed commit, you can use 'git revert' to create a new commit that undoes the changes, preserving history. Avoid using 'git reset' on shared branches, as it rewrites history and can cause issues for collaborators.

'git reset' moves the current branch pointer and can modify the staging area and working directory, often used to undo commits locally. 'git checkout' switches branches or restores files. 'git revert' creates a new commit that undoes the changes of a previous commit, preserving history.

Git is not optimized for large binary files, as they can bloat the repository. To manage them, use Git Large File Storage (Git LFS), which replaces large files with pointers in the repository and stores the actual files on a remote server. This keeps the repository size manageable and improves performance.

'git fetch' downloads new data from a remote repository but does not integrate it into your working files, allowing you to review changes before merging. 'git pull' is a combination of 'git fetch' followed by 'git merge', automatically updating your current branch. Use 'fetch' when you want to inspect changes before integrating, and 'pull' for direct updates.

An interactive rebase ('git rebase -i') allows you to edit, reorder, squash, or remove commits before integrating them into a branch. This is useful for cleaning up commit history, combining related changes, or editing commit messages before merging a feature branch.

'git reflog' records updates to the tip of branches and HEAD, including actions like commits, rebases, and resets. If you lose a commit (e.g., after a reset), you can use 'git reflog' to find its reference and recover it using 'git checkout' or 'git cherry-pick'.

Git submodules allow you to include and manage external repositories within a parent repository. They are useful when your project depends on other projects, enabling you to track and update dependencies independently. Use 'git submodule add', 'update', and 'init' to manage submodules.

Rewriting history (e.g., with 'git rebase' or 'git push --force') on shared branches can disrupt collaborators by invalidating their commit history. It should be avoided on public branches. If necessary, coordinate with your team and use 'git push --force-with-lease' to minimize risk.

Squashing combines multiple commits into a single commit, creating a cleaner, more readable history. This is often done before merging a feature branch to main. Use 'git rebase -i' or the squash option in pull requests. Be aware that squashing rewrites history, so coordinate with collaborators.

'git bisect' uses binary search to efficiently identify the commit that introduced a bug. Mark a known good and bad commit, then Git checks out commits in between for testing. Continue marking good/bad until the culprit is found. This is invaluable for debugging regressions.

A fast-forward merge moves the branch pointer forward if there are no divergent changes, resulting in a linear history. 'git merge --no-ff' creates a merge commit even if a fast-forward is possible, preserving the context of feature branches in history.

During a rebase, conflicts are resolved by manually editing files, staging the resolved changes with 'git add', and continuing the rebase with 'git rebase --continue'. Best practices include rebasing frequently, resolving conflicts promptly, and communicating with your team.

'git worktree' allows you to have multiple working directories linked to a single repository, enabling you to work on different branches simultaneously without cloning the repo again. This is useful for testing, hotfixes, or parallel feature development.

A shallow clone ('git clone --depth N') copies only the latest N commits, reducing download size and time. It's useful for CI/CD pipelines or when you only need recent history. However, it limits access to full commit history and some operations like rebasing or merging old commits.

You can sign commits and tags using GPG or SSH keys ('git commit -S', 'git tag -s'). Signed commits verify authorship and integrity, which is important for security-sensitive projects and open source contributions. Configure signing with 'git config' and your key.

If a remote branch is force-pushed, your local branch may diverge. To resolve, fetch the latest changes, create a backup of your local branch, then reset or rebase onto the new remote branch. Communicate with your team to avoid data loss.

You can add multiple remotes using 'git remote add', fetch from them, and push to them as needed. This is useful for collaborating across forks or mirroring repositories. Use remote names (e.g., 'origin', 'upstream') to specify actions per remote.

'git blame' shows which commit and author last modified each line of a file, helping track changes and identify the origin of bugs or features. Use it to understand code history, but combine with 'git log' and 'git show' for full context.

'git filter-branch' rewrites history to modify commits, such as removing sensitive data or changing author info. It's powerful but slow and error-prone. Alternatives like 'git filter-repo' are faster and safer. Always back up your repository before rewriting history.

Git hooks can trigger scripts on events like commits or pushes, enabling automated code formatting, linting, or tests. For more advanced automation, integrate Git with CI/CD tools (e.g., GitHub Actions, Jenkins) to run builds, tests, and deployments on repository events.