1. What does `git add` do? What’s the staging area?
`git add` places changes into the index (staging area), a buffer where you curate what will go into the next commit.
Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Wipro · Git & Version Control
Practice Git & Version Control questions specifically asked in Wipro interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
64
Tagged for this company + subject
Company
Wipro
View company-wise questions
Subject
Git & Version Control
Explore topic-wise practice
Go through each question and its explanation. Use this page for targeted revision just before your Wipro Git & Version Control round.
`git add` places changes into the index (staging area), a buffer where you curate what will go into the next commit.
For complete preparation, combine this company + subject page with full company-wise practice and subject-wise practice. You can also explore other companies and topics from the links below.
Use `-d` for safe deletion (already merged). `git fetch --prune` cleans stale remote-tracking refs.
Reflog records movements of HEAD and refs (even orphaned). It’s crucial for recovering "lost" commits after resets/rebases or branch deletions.
`git restore <path>` replaces the file from HEAD (modern replacement for `checkout --`).
CODEOWNERS maps paths to responsible reviewers and can be required by branch rules.
Merging preserves history and is non-destructive but adds merge commits. Rebasing keeps a linear history but rewrites commits and requires force-push to the PR branch.
CODEOWNERS maps file globs to teams/users, auto-requesting reviews and enforcing approvals.
Change impact analysis plus mandatory checks protects downstream packages.
A remote is a named reference to another copy of the repository, typically hosted on a server. 'origin' is the default name Git assigns when you clone, pointing back to the source repository. It lets you fetch, pull, and push changes for collaboration.
Modern Git: `git switch -c <name>` creates and checks out. Classic equivalent: `git checkout -b <name>`.
`git stash` saves local modifications (tracked files) for later: use `stash pop/apply` to restore.
It refuses to overwrite remote work you haven’t fetched, offering a safety check.
Squash yields a single commit; good for tidy history, but loses granular commit info.
Rewrites change commit IDs, breaking collaborators’ history and remotes. Mitigate with protected branches, disallowing force-push, using merge on shared branches, and rewriting only private branches.
Local delete with `git tag -d`; remote delete with a push of an empty ref to the tag.
Git is a distributed version control system (DVCS) created by Linus Torvalds for fast, reliable source control. It enables branching/merging, offline work, and full history on every clone—ideal for team collaboration and safe iteration.
A commit is a snapshot of staged changes with metadata (hash, author, time). Clear messages explain intent, aid code review, and improve traceability.
Branches let you isolate work (features, fixes, experiments) without disrupting the main line. In Git, branches are lightweight pointers to commits, so creating/switching is fast and storage-efficient.
A fast-forward moves the branch pointer when no divergent commits exist; no merge commit is created. `--no-ff` forces a merge commit to preserve feature-branch context—useful for code review traceability and keeping logical units in history.
HEAD moves back two commits; index and working tree keep the changes from those commits staged. Useful to reword/squash into a single commit.
`git cherry-pick <hash>` applies the changes from a specific commit onto the current branch. Commonly used to backport a hotfix commit from `main` to a release branch without merging all other changes.
`pull --rebase` rewrites local work on top of fetched commits, avoiding a merge commit for a linear history.
Keep subject line ≤50 chars in imperative mood (e.g., "Fix crash on null input"). Add a blank line, then a body explaining what and why (context, impact, links).
`restore --staged` removes from Index only; the file contents remain in the working tree.
`--fixup <hash>` creates a targeted fix commit labeled for autosquash. Later `rebase -i --autosquash` reorders and squashes fixups onto their intended commits automatically, keeping a tidy history.
An upstream branch is the remote branch your local branch integrates with by default for pull/push. Set it via `git branch --set-upstream-to=origin/main` or on first push using `git push -u origin <branch>`.
`push.default=simple` pushes the current branch to its upstream of the same name and rejects if names differ. `git push --all` pushes all local branches that have matching names to the remote.
`--depth 1` creates a shallow clone with truncated history for speed and reduced size.
A submodule embeds another repo at a specific commit. After cloning, run `git submodule init` then `git submodule update` (or `git submodule update --init --recursive`) to fetch and checkout submodule contents.
Run `git rebase -i HEAD~3`; change second/third `pick` to `squash` (or `fixup`); save, then edit the combined message and complete the rebase.
Stage the resolved files and continue. You do not create a manual commit during rebase steps.
Rebasing avoids merge bubbles, and squashing yields a single, reviewed commit per PR while PR metadata preserves context.
Working tree = your files on disk; index = staged snapshot for the next commit; HEAD = pointer to the last commit of the current branch. Most history edits move HEAD; file-level fixes move working tree or index.
Revert creates a new inverse commit, preserving subsequent history.
`git restore --staged app/config.yml` (or `git reset app/config.yml`) removes it from the index but leaves file changes on disk.
Branches isolate work so features, fixes, and experiments can proceed without impacting the main line. They allow concurrent workflows, easier code review via PRs, and controlled integration back to trunk.
If no divergence exists, Git advances the pointer (no merge commit).
Merge preserves history with a merge commit—good for shared branches. Rebase rewrites the feature to sit atop main—clean linear history, ideal before opening a PR. Avoid rebasing public branches.
Review promptly, be specific and kind, ask clarifying questions, suggest concrete changes, verify tests/docs, pull locally when needed, and approve only after required checks pass.
Trunk-based or short-lived feature branches; protect `main` with CI; feature toggles for incomplete work; cut `release/*` branch weekly for stabilization; hotfix branches from `main`; merge via PR with squash; tag releases.
Stash lets you temporarily shelve uncommitted changes so you can switch branches, pull fixes, or review code with a clean tree. Later you reapply the changes, avoiding throwaway commits or losing work.
Branches isolate work (features, fixes, experiments), keep main stable, enable review and CI per branch, and simplify rollback/cleanup without risking production code.
`-u/--include-untracked` adds untracked files; use `-a` to include ignored too.
Modern syntax uses `git stash push -m "message"` to label the stash.
`git clean` removes untracked files/dirs from the working tree. It permanently deletes files not tracked by Git, so use `-n` (dry-run) first to preview.
Require PR reviews, require status checks (CI) to pass, disallow force-pushes, require up-to-date with base, enforce signed commits, and restrict who can push.
Create `fixup! <subject>` commits to mark quick corrections. With `--autosquash`, interactive rebase auto-positions those fixups next to their targets for clean squashing.
Tags mark important points in history (e.g., releases). Annotated tags store metadata (tagger, date, message, signature) and are ideal for official releases; lightweight tags are simple pointers for personal bookmarks.
`-s` signs the tag with your configured GPG key for provenance.
A release is metadata built around a tag: rich notes, attachments (artifacts), checksums, and visibility controls—useful for distributing binaries and changelogs.
`git describe` finds the nearest tag; `--abbrev=0` prints only the tag name.
Structured context improves review quality and deploy safety.
Enforce squash to keep a clean, one-commit-per-PR history and easy revert. Trade-offs: lose granular interim commits and bisect fidelity; mitigate by writing a thorough squash message and linking PR.
The Index is a middle layer between your working tree and the repository. You choose exactly which changes to include in the next snapshot (commit), enabling partial commits and clean, reviewable history.
`git init` bootstraps a repository in the current folder; `git clone` fetches an existing repo, files, branches, and history.
Edit to resolve, stage resolved files, then commit. During rebase, you’d use `git rebase --continue` after `git add`.
Lightweight tags are simple pointers to a commit. Annotated tags (`git tag -a`) store metadata (tagger, date, message, GPG sig). Use annotated tags for releases; lightweight tags for local/bookmark usage.
Git Flow favors release cycles (develop, release, hotfix) for products with scheduled releases. GitHub Flow suits continuous delivery with short-lived feature branches and PRs to main. Trunk-based emphasizes committing to main behind flags with tiny branches for rapid integration. Choose based on cadence, compliance, and team size.
`-X ours` is a strategy option for the recursive strategy preferring current branch on a path-level conflict; `-s ours` discards the other tree entirely.
1) Commit or stash WIP (`git stash -p -m "wip"`). 2) Verify status (`git status`, `git stash list`). 3) Clean dry-run (`git clean -ndx`). 4) If OK, run `git clean -fdx` for a pristine tree. 5) Reapply stashed pieces as needed with `git stash apply` and re-stage.
Rebase replays commits from your branch onto a new base, creating new commit IDs and a linear history. It’s a rewrite; the old commits are replaced by equivalent ones atop the target base.
Resolve conflicts, `git add`, then `--continue`; use `--abort` to return to pre-rebase state.
`A..B` applies commits reachable from B but not A (lower bound exclusive).
GitHub Flow (trunk-based: small feature branches → PR → merge to main → deploy) fits products that deploy very frequently and value simplicity. Git Flow (long-lived develop, release/hotfix branches) suits scheduled releases and heavier QA gates. Choose the simplest model that matches release cadence and compliance needs.