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
Cognizant · Git & Version Control
Practice Git & Version Control questions specifically asked in Cognizant interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
45
Tagged for this company + subject
Company
Cognizant
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 Cognizant Git & Version Control round.
Use `git branch --set-upstream-to=<remote>/<branch>` from the local branch. Alternatively, the first push can set it: `git push --set-upstream origin <branch>`.
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 `git log --grep "keyword"` to locate by message; then `git show <hash>` (optionally `-p --stat`) to view the diff and metadata.
`--autosquash` pairs `fixup!`/`squash!` commits with their targets in the todo list.
Create a branch (`git switch -c`) if you intend to keep commits.
CODEOWNERS maps paths to responsible reviewers and can be required by branch rules.
Squash condenses all PR commits into one for a tidy history.
Rewrite only private/unpushed history to avoid disrupting collaborators.
CODEOWNERS maps file globs to teams/users, auto-requesting reviews and enforcing approvals.
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.
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.
`status` summarizes tracked/untracked/staged; `diff` shows content differences.
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`).
First push with `--set-upstream` ties the local branch to its remote tracking branch.
`--oneline --graph --decorate` for a compact, visual branch graph; `--stat` to see per-file change summary; `-p` to display patch/diffs for each commit.
`git add -p` lets you review and stage hunks interactively for granular commits.
`--soft` moves HEAD only (keeps Index/WT), `--mixed` moves HEAD and resets Index (keeps WT), `--hard` resets HEAD, Index, and Working Tree (destructive).
`pull` first fetches remote tracking changes then integrates them, while `fetch` only updates remote-tracking refs.
`--tags` tells Git to send all tag refs to the target remote.
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`.
Rebase copies your commits onto the target tip (new IDs), producing a straight line; merge records a join, keeping parallel history.
Use `git reflog` to find the pre-rebase HEAD (e.g., `HEAD@{1}`) and `git reset --hard <that-id>` or create a rescue branch from it. Reflog records past HEAD positions.
`--mixed` (default) moves HEAD and resets index to the commit, keeping your working files.
`--no-ff` keeps a merge node even if fast-forward is possible, preserving feature context.
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.
Policy: feature branches rebase onto latest main; PRs merge with squash or rebase-merge; disallow merge commits on main. Steps: `git fetch`, `git rebase origin/main`, resolve, push with `--force-with-lease`, then squash-merge PR.
`git stash` (or `git stash push`) stores current tracked changes and resets the worktree.
`-u/--include-untracked` adds untracked files; use `-a` to include ignored too.
`-d` removes untracked directories; `-f` is required to actually perform deletion.
When you need only specific commits (e.g., a hotfix) without bringing other work, to keep a minimal, controlled change set.
`-a` creates an annotated tag and `-m` sets its message.
MAJOR → incompatible, MINOR → new compatible features, PATCH → bug fixes.
`-s` signs the tag with your configured GPG key for provenance.
Branch protection with mandatory reviews and passing CI prevents broken code and history rewrites.
Acknowledge the concern, provide evidence (benchmarks, standards), seek compromise, or escalate to documented guidelines/architects. Never ignore feedback; document the decision in the PR for future readers.
List with `git stash list`. Inspect with `git stash show -p stash@{n}` to see the patch, or `git show stash@{n}` for full object details.
Pushing an empty ref (`:<name>`) deletes the remote branch. Modern alternative: `git push origin --delete feature/login`.
Squash merge maintains a clean history with one commit representing the PR.
`--hard` aligns index and working tree to the target commit; untracked files remain unless cleaned.
`git switch -C` creates (or resets) and checks out the branch in one step.
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.
GitHub Flow favors small feature branches off main with PR review and continuous delivery.
Automate SemVer bumps on protected branch and create annotated (optionally signed) tags with release notes.
Threat-aware review plus automated secret scanning and SCA improves security posture.