Git & DevOps Version Control Interview Questions
Deep-dive answers covering advanced branching, rebasing, GPG signing, Git hooks, submodules, reflog, and GitOps pipelines.
What is the difference between 'git init' and 'git clone', and when would you use each?
'git init' creates a blank, local Git repository in an existing project directory, while 'git clone' copies an existing remote Git repository onto your local machine, automatically setting up a remote tracking link.
Key Takeaways & Core Strategy
- β'git init' sets up a hidden '.git' folder locally and doesn't configure remote URLs automatically.
- β'git clone' copies history, commits, and branches, and sets up a default remote alias named 'origin'.
- β'git clone' accepts HTTPS, SSH, and file directory paths as URLs.
β οΈ Senior Engineering Warning
Do not run 'git init' inside an existing Git repository (nested repos). Make sure to check if a project is already tracked before initializing a new repository.
Deep Dive Explanation
Use 'git init' when you are starting a new project locally from scratch or taking an existing unversioned folder and converting it into a Git repository. Use 'git clone' when the repository already exists on a hosting provider (like GitHub or Bitbucket) and you want to download it and start contributing.
# Start a new local repository
mkdir my-new-project
cd my-new-project
git init
# Clone an existing remote repository
git clone https://github.com/careerraah/playwright-tests.gitHow does the 'git status' command help you manage your working directory and staging area?
'git status' displays the state of your working directory and staging area, listing files that are modified but unstaged, files staged for the next commit, and untracked files.
Key Takeaways & Core Strategy
- βShows unstaged changes in red (modified files in working directory).
- βShows staged changes in green (ready to be committed in the index).
- βIdentifies untracked files that Git has not started version-controlling.
- βDisplays branch state relative to the tracked upstream branch.
β οΈ Senior Engineering Warning
Do not assume files listed under 'Untracked files' will be included in your commit. You must explicitly run 'git add' on untracked files before committing.
Deep Dive Explanation
'git status' is a safe, non-destructive inspection tool. It tells you which local changes are currently ready to be committed, which modified files still need to be staged, and which files are ignored or untracked. It also shows whether your local branch is ahead, behind, or synced with its remote counterpart.
# Check current staging and working directory status
git statusExplain the differences between staging files with 'git add <file>', 'git add .', and 'git add -A'.
'git add <file>' stages a single specific file, 'git add .' stages all new and modified files in the current folder and subfolders (but ignores deleted files in older Git versions), while 'git add -A' stages all changes globally, including modifications, additions, and deletions.
Key Takeaways & Core Strategy
- βStaging acts as a buffer index before final committing.
- β'git add -A' stands for 'Add All' and stages every modification, untracked addition, and deletion.
- βUsing specific file staging ('git add <file>') is safer to prevent committing local debug logs or secrets.
β οΈ Senior Engineering Warning
Avoid blindly running 'git add .' or 'git add -A' without checking your changes first, as you might accidentally stage sensitive credentials, node_modules, or build artifacts.
Deep Dive Explanation
Staging prepares changes for the next commit. In modern Git (version 2.x+), both '.' and '-A' stage deletions, but 'git add .' is restricted to the current directory and its descendants, whereas 'git add -A' stages all changes in the entire working repository regardless of your current directory location.
# Stage a single file
git add src/tests/login.spec.ts
# Stage all files in the current directory tree
git add .
# Stage all changes in the entire repository (including deletions)
git add -AWhat is the purpose of 'git commit', and how does the '-m' flag work?
'git commit' saves your staged changes to the local repository's version history, creating a unique commit hash. The '-m' flag allows you to write the commit message directly in the terminal instead of opening a default text editor.
Key Takeaways & Core Strategy
- βCreates a cryptographic SHA-1 hash to uniquely identify the change snapshot.
- βAppends the change permanently to the current local branch history.
- βFollow semantic commit guidelines (e.g. 'feat:', 'fix:', 'docs:') to help automate releases.
β οΈ Senior Engineering Warning
Never commit code with empty or generic messages like 'temp', 'fix', or 'update'. A bad commit history makes debugging regressions extremely difficult.
Deep Dive Explanation
A commit is a snapshot of your project's index at a specific moment. Writing clean, descriptive commit messages is vital for teamwork. If you run 'git commit' without the '-m' flag, Git will open your system's default text editor (like vim or nano) to write a multi-line commit message.
# Commit staged changes with a inline message
git commit -m "feat(auth): add email verification to login tests"How do 'git push' and 'git pull' commands sync code with a remote repository?
'git push' uploads your local branch commits to the remote repository (e.g. GitHub), while 'git pull' downloads (fetches) the latest changes from the remote repository and automatically merges them into your active local branch.
Key Takeaways & Core Strategy
- β'git push' fails if your local branch is behind the remote, requiring a pull first.
- β'git pull' can cause merge conflicts if remote changes overlap with un-synced local edits.
- βRunning 'git pull --rebase' is a common practice to maintain a clean, linear git history.
β οΈ Senior Engineering Warning
Do not run 'git pull' when you have unstaged or uncommitted changes in your working directory, as Git might block the pull or complicate conflict resolution.
Deep Dive Explanation
Working in teams requires syncing histories. 'git push' pushes local commits to update the remote. 'git pull' is actually a combination of two operations: first, it runs 'git fetch' to download remote updates, and second, it automatically runs 'git merge' to merge those updates into your working branch.
# Push local commits to remote branch
git push origin feature-login
# Pull latest changes from remote tracking branch
git pull origin mainHow do you use 'git log' and 'git diff' to inspect past commits and review uncommitted modifications?
'git log' displays the chronological history of commits on your active branch, while 'git diff' displays the line-by-line differences between your current working directory and the staged index (unstaged changes).
Key Takeaways & Core Strategy
- β'git log' can be filtered by file path, author, date range, or commit count.
- β'git diff' without flags only compares files that are modified but NOT yet staged.
- βTo view details of a specific past commit, use 'git show <commit_hash>'.
β οΈ Senior Engineering Warning
Do not execute a commit without reviewing your diff first. Running 'git diff --staged' prior to committing guarantees that only intended changes are stored.
Deep Dive Explanation
'git log' shows commit metadata (author, date, message, hash) so you can review history. 'git diff' displays additions (green `+` lines) and deletions (red `-` lines). To inspect staged changes, use 'git diff --staged'.
# View commit history
git log
# View simplified one-liner history
git log --oneline
# View unstaged code changes
git diff
# View staged changes preparing for commit
git diff --stagedHow do you create, list, and switch between branches in Git?
Use 'git branch' to list local branches, 'git branch <branch_name>' to create a new branch, and 'git checkout <branch_name>' (or 'git switch <branch_name>') to switch branches. You can also run 'git checkout -b <branch_name>' to create and switch in one step.
Key Takeaways & Core Strategy
- βBranches are lightweight pointers to specific commits.
- βA local branch must be pushed to remote explicitly to share it with the team.
- βKeep branch names structured (e.g., 'feature/', 'bugfix/', 'hotfix/').
β οΈ Senior Engineering Warning
Do not switch branches when you have active, uncommitted work in progress, unless you are willing to carry the changes over or stash them first.
Deep Dive Explanation
Branching creates isolated lines of development. You can work on features or fixes safely without affecting the stable 'main' branch code. In modern Git versions, the 'git switch' command is preferred over 'git checkout' for switching branches, to separate branch operations from file restoration.
# List all local branches
git branch
# Create a new feature branch
git branch feature-dashboard
# Switch to the feature branch
git checkout feature-dashboard
# OR: git switch feature-dashboard
# Create and switch in a single command
git checkout -b feature-payment
# OR: git switch -c feature-paymentWhat is the difference between a Fast-Forward merge and a 3-Way merge?
A Fast-Forward merge occurs when the source branch has no new commits since the target branch branched off, allowing Git to simply move the target pointer forward. A 3-Way merge occurs when both branches have diverged with new commits, requiring Git to create a new 'Merge Commit' combining the histories.
Key Takeaways & Core Strategy
- βFast-Forward merges leave a clean, straight history line without extra commits.
- β3-Way merges create a dedicated 'merge commit' representing the point of integration.
- βFast-forwarding can be disabled globally or per-merge to preserve feature branch records.
β οΈ Senior Engineering Warning
Never run 'git merge --no-ff' on local developer branches where clean squashing is preferred. Reserve non-fast-forward merges for integrating PRs into target production branches.
Deep Dive Explanation
If you merge a branch and no commits occurred on the base branch (like 'main') in the meantime, it's a Fast-Forward merge, leaving no merge commit. If the base branch has moved, Git finds the common ancestor of both branches and performs a 3-way merge. To enforce a merge commit even during Fast-Forward conditions, use 'git merge --no-ff'.
# Merge branch into current (triggers Fast-Forward if main is unmodified)
git checkout main
git merge feature-login
# Force a merge commit (no fast-forward) for tracking pull requests
git merge --no-ff feature-loginWhat causes a Git merge conflict, and how do you resolve it?
A merge conflict occurs when two branches make conflicting edits to the exact same line of a file (or one deletes a file the other modified) and Git cannot determine which version to keep. It must be resolved manually by editing the conflicted files, staging them, and committing.
Key Takeaways & Core Strategy
- βConflicts must be resolved before completing the commit.
- βYou can cancel the merge at any time and revert your branch state using 'git merge --abort'.
- βUse a diff tool or IDE conflict resolver (like VS Code or IntelliJ) to make resolutions simpler.
β οΈ Senior Engineering Warning
Do not guess when resolving conflicts. Consult with the teammate who wrote the conflicting changes to ensure you don't accidentally erase their work.
Deep Dive Explanation
When Git encounters conflicts during a merge, it halts and marks the conflicted sections inside the files with conflict markers: `<<<<<<< HEAD` (your active branch changes), `=======` (separator), and `>>>>>>> branch_name` (incoming changes). To resolve, delete the markers, choose or rewrite the correct lines, run 'git add' to stage the files, and complete the merge with 'git commit'.
# Run merge and check status if it fails
git merge feature-payment
# (Edit files to resolve conflict markers)
# Stage resolved files
git add src/payments.ts
# Complete merge execution
git commit -m "merge: resolve merge conflicts in payments"How do you configure your developer identity in Git, and what is the difference between global and local configuration?
Identity is configured using 'git config user.name' and 'git config user.email'. Global configurations apply to all repositories on your local computer, while local configurations override global values for a single specific repository.
Key Takeaways & Core Strategy
- βGlobal configs are stored in your home directory (e.g. '~/.gitconfig').
- βLocal configs are stored within the project directory (e.g. '.git/config').
- βVerify all active configurations by running 'git config --list'.
β οΈ Senior Engineering Warning
Do not commit code with misconfigured email aliases. If your email is wrong, your commits won't link to your GitHub profile, and you might leak personal emails on public repositories.
Deep Dive Explanation
Git needs to know who authored each commit. Setting configuration globally makes it the default for all repositories. If you work on corporate repositories (requiring your company email) and open-source repositories (using personal email) on the same machine, you override the global settings by running the config command locally inside the corporate folder without the '--global' flag.
# Set global user name and email
git config --global user.name "John Doe"
git config --global user.email "john.doe@personal.com"
# Override for a specific work project repository
cd work-repos/fintech-app
git config user.email "jdoe@company.com"π‘ Looking for a Quick Reference?
Download or view our interactive Git Commands Cheat Sheet featuring 1-click clipboard copy and category filters.

Finished practicing?
Head back to the main lobby to explore more interview prep tracks and dashboard tools.
Have a specific question? Ask our AI Coach!
Explore custom roadmaps, ask technical questions, and design your QA and AI interview preparation path.