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
Infosys · Git & Version Control
Practice Git & Version Control questions specifically asked in Infosys interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
59
Tagged for this company + subject
Company
Infosys
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 Infosys 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.
`-S` signs the commit. Configure with `user.signingkey` and GPG agent beforehand.
This combo visualizes branch tips and relationships succinctly across all refs.
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>`.
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.
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.
'.gitignore' tells Git which files/paths not to track (e.g., builds, secrets). Common patterns: 'node_modules/' and '*.log'. This keeps history clean and avoids committing noise or sensitive data.
# .gitignore node_modules/ *.log .DS_Store /dist/
Stage with `add`, create a snapshot with `commit`, then publish with `push`.
`status` summarizes tracked/untracked/staged; `diff` shows content differences.
Use it to fix the last commit’s message or add missed changes. It rewrites history, so avoid amending commits already pushed/shared.
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.
`git merge <branch>` integrates that branch into the current HEAD.
`revert` creates a new commit that negates the changes without rewriting history, safe for shared branches.
`--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.
`restore --staged` removes from Index only; the file contents remain in the working tree.
`--staged` (aka `--cached`) shows Index vs HEAD; plain `git diff` shows WT vs Index.
`pull` first fetches remote tracking changes then integrates them, while `fetch` only updates remote-tracking refs.
`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.
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`.
`git restore <path>` restores file content in working tree from HEAD (or a commit). `git restore --staged <path>` un-stages changes (like `git reset <path>`). They split file restore from branch switching for clarity.
Run `git rebase -i HEAD~3`; change second/third `pick` to `squash` (or `fixup`); save, then edit the combined message and complete the rebase.
Use it to transplant a range of commits onto a different base, skipping earlier ones. Example: move `featureA` commits that diverged from `topic` onto `main`: `git rebase --onto main topic featureA`.
An octopus merge merges more than two branches in a single commit. It’s suitable for merging many independent topic branches without conflicts; avoid when manual conflict resolution is required.
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.
`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.
`--no-ff` keeps a merge node even if fast-forward is possible, preserving feature context.
1) `git merge origin/main` → non-destructive, may create merge commits. 2) `git rebase origin/main` → linear history, rewrites commits (avoid if already shared).
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.
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.
It stashes only unstaged changes while leaving the index intact. Useful before running tests/CI on exactly what is staged for commit without noise from local WIP.
`-p/--patch` lets you interactively pick hunks to stash.
`-x` makes `clean` also remove ignored files; pair with `-f` to apply.
Clear title, description (problem, approach, scope), links to issues/tickets, screenshots/logs, test notes, checklist, and small, focused commits.
They’re easier to review, reduce cycle time, lower defect risk, improve merge success, and aid revertability.
Keywords like “Fixes/Closes/Resolves #id” close the issue on merge to default branch.
`--signoff` appends a DCO sign-off line to the commit message.
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.
Highlights, breaking changes, migration steps, bug fixes, known issues, contributors, and links to diffs/PRs. Keep crisp and user-centric.
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.
Interactively rebase the feature branch onto the latest main and squash noisy merges into logical commits. This yields a linear, readable history while preserving meaningful changes. Avoid rewriting history only after the branch is shared publicly unless teammates agree.
Structured context improves review quality and deploy safety.
Early collaboration reduces rework and aligns on approach.
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.
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.
Rotate the secret. Use `git filter-repo` (or BFG) to purge the file/paths from all commits, force-push with lease, invalidate caches, and update PRs. Add patterns to `.gitignore` to prevent recurrence.
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.
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.