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
Capgemini · Git & Version Control
Practice Git & Version Control questions specifically asked in Capgemini interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
41
Tagged for this company + subject
Company
Capgemini
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 Capgemini Git & Version Control round.
`-S` signs the commit. Configure with `user.signingkey` and GPG agent beforehand.
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.
Rewriting history creates new commits; force-push would be required and can disrupt collaborators.
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.
Conventional Commits use type(scope?): subject — e.g., feat, fix, chore, docs — aiding automation and changelogs.
Change impact analysis plus mandatory checks protects downstream packages.
Local delete with `git tag -d`; remote delete with a push of an empty ref to the tag.
`git fetch` downloads new refs/history without altering your working branch. `git pull` = fetch + merge (or rebase), integrating changes into the current branch.
A repository stores your project files and their version history. A local repo lives on your machine (.git); a remote repo (e.g., GitHub/GitLab) is a shared copy used for collaboration and backup.
Stage with `add`, create a snapshot with `commit`, then publish with `push`.
A conflict arises when Git can’t auto-merge edits (e.g., same line differs). Open files, choose the correct content, save, `git add` the fixes, then `git commit` (or `--continue`).
`git switch -c <name>` is the newer, intent-specific command. The classic equivalent is `git checkout -b <name>`.
HEAD moves back two commits; index and working tree keep the changes from those commits staged. Useful to reword/squash into a single commit.
`merge` combines histories and may create a merge commit; it preserves chronology from all contributors. `rebase` rewrites commits on top of a new base for a linear history—clean but dangerous if used on shared/pushed commits. Rebase private branches; avoid rebasing public history.
`revert` creates a new commit that negates the changes without rewriting history, safe for shared branches.
Annotated tags store tagger, date, and message—ideal for releases. Create with `git tag -a v1.2 -m "Release"` and push using `git push origin v1.2`.
`--soft` moves HEAD only (keeps Index/WT), `--mixed` moves HEAD and resets Index (keeps WT), `--hard` resets HEAD, Index, and Working Tree (destructive).
`--staged` (aka `--cached`) shows Index vs HEAD; plain `git diff` shows WT vs Index.
`git remote set-url` updates the fetch/push URLs for a named remote.
`--prune` deletes local stale remote-tracking branches (e.g., origin/feature-x) removed from the remote.
`--rebase` linearizes history by replaying local commits over the updated upstream.
In fork-based workflows, `origin` is your fork; `upstream` is the source project. You fetch from `upstream` to stay current, rebase your feature branch, push to `origin`, and open a PR back to `upstream`.
`--no-ff` creates a merge commit even if HEAD could fast-forward, keeping branch context for later tracing/reverts.
Rebasing rewrites commit IDs, breaking collaborators’ histories. It’s safe on private/local branches before pushing or when everyone coordinates (e.g., force-push with lease) and consumers are ready.
Use `git reflog` to find the previous HEAD (e.g., `HEAD@{2}`) then `git branch rescue HEAD@{2}` or `git reset --hard <that-id>` to restore the state.
Fetch updates, then hard-reset branch to the remote tip (tracked files).
If no divergence exists, Git advances the pointer (no merge commit).
This ties the current local branch to a remote tracking branch for pull/push defaults.
`-u/--include-untracked` adds untracked files; use `-a` to include ignored too.
Modern syntax uses `git stash push -m "message"` to label the stash.
`-d` removes untracked directories; `-f` is required to actually perform deletion.
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.
Tag fixups (`fixup! subject`) then run interactive rebase with `--autosquash`.
`-s` signs the tag with your configured GPG key for provenance.
`git describe` finds the nearest tag; `--abbrev=0` prints only the tag name.
Gentle automation plus education shapes behavior without stalling delivery.
`-u` stages tracked file modifications and deletions; it skips new untracked files.
`-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.
`A..B` applies commits reachable from B but not A (lower bound exclusive).
Smaller diffs are easier to review thoroughly and roll back when needed.