Q: What is the difference between continuous integration, continuous delivery and continuous deployment?

They're three increasing levels of automation. Continuous integration (CI): developers merge small changes into the main branch frequently, at least daily, and every push or pull request triggers an automated build and test run. The goal is fast feedback and a main branch that is always green. Continuous delivery: every change that passes the pipeline produces an artifact that is ready to release and has been deployed to production-like environments. Going to production is a push-button business decision, often with an approval step. Continuous deployment: there's no manual gate. Every change that passes all the automated checks is deployed to production automatically. Continuous deployment only works with strong automated tests, good monitoring and alerting, feature flags to hide unfinished work, and fast, reliable rollback. Many teams practise continuous delivery and keep a human approval for production.

Question 1

What is the difference between Git and GitHub (or GitLab)?

Accepted Answer

Git is a distributed version control system: a tool that records the history of your project in a repository on your own machine. Every clone holds the full history, so you can commit, branch, diff and read the log completely offline. GitHub and GitLab are hosting platforms built around Git. They store a shared remote copy of the repository and add collaboration features that Git itself doesn't have: - pull requests (merge requests on GitLab) and code review - issues, permissions and branch protection - CI/CD: GitHub Actions, GitLab CI/CD - releases, package and container registries Git doesn't depend on them at all: you can push to any server over SSH or HTTPS, or to a plain directory. A good way to say it: Git is the engine, GitHub and GitLab are services where teams park and review what the engine produces.

Question 2

Explain the working tree, the staging area (index) and the repository. Why does Git have a staging area?

Accepted Answer

Git keeps your files in three places: - Working tree: the files you actually see and edit on disk. - Staging area (index): a snapshot of what the *next* commit will contain. git add copies the current content of a file into it. - Repository: the .git directory, holding every commit, tree and blob plus the refs that point at them. git commit turns the index into a new commit. The staging area lets you build a commit deliberately instead of committing everything that changed. If you fixed a bug and also refactored something unrelated, you can stage and commit them separately, even individual hunks with git add -p, which makes history easier to review, revert and bisect. The matching diffs: git diff shows working tree vs index, and git diff --staged shows index vs the last commit.

Question 3

What is the difference between git merge and git rebase, and when would you use each?

Accepted Answer

Both bring changes from one branch into another, but they record history differently.

Merge joins two lines of history. If the target hasn't moved since you branched, Git just moves the pointer forward (a fast-forward). Otherwise it creates a merge commit with two parents. Nothing is rewritten, so it's always safe on shared branches, but history can become a tangle of merge bubbles.

Rebase takes your commits and replays them one by one on top of another base, creating new commits with new SHAs. The result is a linear history, as if you'd started from the latest main.

The golden rule: don't rebase commits that other people already have, such as a shared branch, because you'd rewrite history they built on.

In practice: rebase your own feature branch onto main to stay current and tidy it up before review; merge (or squash-merge via the PR) to integrate into shared branches.

Question 4

What is the difference between git fetch and git pull? What does git pull --rebase do?

Accepted Answer

git fetch downloads new commits from a remote and updates your remote-tracking branches such as origin/main. It never touches your local branches or working tree, so it's always safe: you can inspect what changed before deciding what to do. git pull is fetch plus integrate: after fetching, it merges the upstream branch into your current branch, or rebases onto it if configured. If your branch can simply fast-forward, it does that. If both sides have new commits and you haven't configured a preference, modern Git stops with "Need to specify how to reconcile divergent branches" and asks you to set pull.rebase or pull.ff. git pull --rebase replays your local unpushed commits on top of the fetched upstream instead of creating a merge commit, which avoids noisy "Merge branch 'main' of ..." commits. Also note: git status saying "up to date" only reflects your last fetch.

Question 5

Explain git reset --soft, --mixed and --hard. How is that different from git revert?

Accepted Answer

git reset moves the current branch pointer to another commit. The mode decides what happens to the index and working tree: - --soft: only the branch moves; the undone changes stay staged. Handy for re-doing or combining the last few commits. - --mixed (the default): the index is reset too, so changes remain in your files but unstaged. - --hard: index and working tree are overwritten. Uncommitted work is lost; the dropped commits are recoverable only through the reflog. git revert doesn't move anything backwards. It creates a new commit that applies the inverse of an existing one, so history is preserved. The rule of thumb: use reset on local commits nobody else has; use revert for anything already pushed to a shared branch, because rewriting shared history forces everyone else to recover.

Question 6

How do you resolve a merge conflict? Walk me through it.

Accepted Answer

A conflict happens when both sides changed the same lines (or one side edited a file the other deleted) and Git can't decide automatically.

Run git status to see the files marked "both modified".
Open each file. Between <<<<<<< and ======= is your side (HEAD), and between ======= and >>>>>>> is the incoming side. With merge.conflictStyle set to zdiff3 (or diff3), Git also shows the common ancestor, which makes the intent of each side much clearer.
Edit the code into the correct combined result and delete the markers. Sometimes you keep one side wholesale with git checkout --ours or --theirs.
git add each file to mark it resolved, run the tests, then git commit (or git rebase --continue).

If it goes wrong, git merge --abort returns you to the state before the merge. Prevention is better: small PRs and frequent integration keep conflicts small.

Question 7

What does git stash do, and what are its gotchas?

Accepted Answer

git stash saves your uncommitted changes, both staged and unstaged, onto a stack and resets the working tree to HEAD. It's useful when you need a clean tree to switch branches, pull or check something quickly without making a throwaway commit. - git stash pop reapplies the latest entry and drops it; git stash apply reapplies but keeps it. - git stash list shows entries as stash@{0}, stash@{1} and so on; -m gives them a readable message. Gotchas: - Untracked files are not stashed by default; use -u (or -a to include ignored files too). - If pop hits a conflict, the entry is not dropped; resolve it and git stash drop yourself. - Stashes are local only. They aren't pushed, and old ones pile up and get forgotten, so for anything longer than a few minutes a WIP commit on a branch is safer.

Question 8

What actually is a branch in Git, and what is HEAD?

Accepted Answer

A branch is just a named, movable pointer to a commit: a ref under refs/heads/ that stores one commit SHA. That's why creating a branch is instant and cheap; Git doesn't copy any files. When you commit on a branch, Git creates the new commit and moves that branch's pointer to it. HEAD is Git's pointer to what you currently have checked out. Normally it's a *symbolic* ref to a branch (ref: refs/heads/main), so new commits advance that branch. If HEAD points directly at a commit instead, you're in detached HEAD state. Useful notation: HEAD~1 (or HEAD~) is the first parent of HEAD, HEAD~3 goes three generations back along first parents, and HEAD^2 is the *second* parent of a merge commit. Tags are also refs, but they're meant to stay fixed, while branches move.

Question 9

What is the difference between continuous integration, continuous delivery and continuous deployment?

Accepted Answer

They're three increasing levels of automation.

Continuous integration (CI): developers merge small changes into the main branch frequently, at least daily, and every push or pull request triggers an automated build and test run. The goal is fast feedback and a main branch that is always green.

Continuous delivery: every change that passes the pipeline produces an artifact that is ready to release and has been deployed to production-like environments. Going to production is a push-button business decision, often with an approval step.

Continuous deployment: there's no manual gate. Every change that passes all the automated checks is deployed to production automatically.

Continuous deployment only works with strong automated tests, good monitoring and alerting, feature flags to hide unfinished work, and fast, reliable rollback. Many teams practise continuous delivery and keep a human approval for production.

Question 10

You just committed with a typo in the message and forgot a file. How do you fix it, and what if you had already pushed?

Accepted Answer

git commit --amend replaces the last commit with a new one built from the current index. Stage the forgotten file, then amend; --no-edit keeps the message, or -m rewrites it. If you want to undo the commit completely but keep the work, git reset --soft HEAD~1. Amending doesn't edit the old commit, it creates a new commit with a new SHA. The old one is still reachable through the reflog for a while. If it's not pushed, that's the end of it. If it is pushed, your local branch and the remote have now diverged, so publishing the fix needs a force push, ideally git push --force-with-lease. That's fine on your own feature branch, but on a shared branch like main don't rewrite history: make a follow-up commit or a git revert instead.

Question 11

How do you throw away all local changes, including untracked files, and get back to the last commit?

Accepted Answer

There are two separate kinds of local change:

Tracked files you modified or staged. git restore --staged --worktree . resets both the index and the files to HEAD; git reset --hard does the same. Plain git restore . only discards unstaged changes.
Untracked files Git has never recorded. Neither command touches them. git clean deletes them: -f is required to actually delete, -d includes directories, and -x also removes ignored files, which may include your .env or local config.

Always run git clean -n (dry run) first, because this is one of the few truly destructive operations: discarded uncommitted work isn't in the reflog and can't be recovered.

If you might want the changes later, git stash -u is the safer option: it clears the working tree but keeps everything, including untracked files, in the stash.

Question 12

What does git cherry-pick do, and when is it the right tool?

Accepted Answer

git cherry-pick takes the changes introduced by an existing commit and applies them as a new commit on your current branch. The new commit has the same diff and message but a different parent, so it gets a different SHA. Typical uses: - Backporting a bug fix from main to a release branch. - Rescuing one useful commit from a branch you're otherwise abandoning. Useful options: -x appends "(cherry picked from commit ...)" to the message, which is great for traceability on release branches; -n applies without committing; a range A..B picks everything after A up to B; -m 1 is needed to pick a merge commit. Conflicts are resolved like a merge, then git cherry-pick --continue. It's not a replacement for merging: if you need most of a branch, merge it. Heavy cherry-picking duplicates commits across branches and makes it hard to tell what has really been shipped where.

Question 13

Compare Git Flow, GitHub Flow and trunk-based development. Which would you pick and why?

Accepted Answer

Git Flow uses two long-lived branches, main (released code) and develop (integration), plus feature/*, release/* and hotfix/* branches. It suits software with versioned, scheduled releases or several supported versions, like installed apps or libraries. For a web service it's heavy: long-lived branches mean big merges and slow feedback. GitHub Flow has one long-lived branch, main, which is always deployable. You create a short-lived branch, open a pull request, CI runs, it gets reviewed, merged and deployed. Simple and a good default for most web teams. Trunk-based development goes further: everyone integrates into trunk at least daily, via very short-lived branches or direct commits, and unfinished work is hidden behind feature flags. Release branches, if any, are cut from trunk. It's what high-performing CI/CD teams tend to use, but it demands good automated tests and discipline. I'd pick GitHub Flow or trunk-based for a continuously deployed service, and Git Flow only when release management genuinely requires it.

Question 14

You added .env to .gitignore, but Git still tracks it. Why, and how do you fix it?

Accepted Answer

.gitignore only applies to untracked files. It stops new files from being picked up by git add and git status, but once a file is tracked, Git keeps tracking changes to it regardless of ignore rules. To fix it, add the pattern and remove the file from the index only with git rm --cached .env (-r for a directory), then commit. The file stays on your disk and is now ignored. Two gotchas: - For everyone else, that commit is a deletion, so when they pull, Git removes the file from their working tree. Warn the team or have them back it up. - The file is still in history. If it contained secrets, treat them as leaked: rotate them, and only then consider rewriting history. git check-ignore -v path tells you which rule ignores a file. For personal ignores that shouldn't be committed, use .git/info/exclude or a global excludes file.

Question 15

What is a squash merge? What are its pros and cons compared with a merge commit or rebase-and-merge?

Accepted Answer

A squash merge combines all of a branch's changes into one new commit on the target. Locally, git merge --squash feature stages the combined result without committing; you then commit it. It isn't a real merge: the new commit has only one parent, so Git doesn't record that feature was merged. On GitHub or GitLab it's the "Squash and merge" button. Pros: one tidy commit per pull request, a linear and readable main, and reverting a whole feature is a single git revert. Messy "fix typo" commits disappear. Cons: the individual commits are lost from main (less useful for bisect and blame on large PRs), and because Git can't see the branch as merged, git branch -d refuses to delete it. If you keep committing on that branch and merge again, you'll get duplicate changes or conflicts. A merge commit keeps every commit plus the branch structure; rebase-and-merge keeps every commit but linearly.

Question 16

You ran git reset --hard and lost commits. How do you get them back?

Accepted Answer

Use the reflog. Every time HEAD or a branch tip moves (commit, reset, rebase, checkout, amend), Git records the old and new position in a local log. Commits that no branch points to still exist in the object database, and the reflog tells you their SHAs. Run git reflog, find the entry just before the mistake, and either create a branch there (git branch rescue <sha>) or move your branch back with git reset --hard HEAD@{1}. ORIG_HEAD also holds the previous tip after a reset, merge or rebase. Limits worth mentioning: - The reflog is local only; it isn't pushed or shared, and a fresh clone has none. - Entries expire (by default after 90 days, or 30 for unreachable commits), after which git gc can prune the objects. - Uncommitted changes discarded by reset --hard were never commits, so the reflog can't help. Previously staged content may survive as dangling blobs (git fsck --lost-found), but that's a long shot.

Question 17

What is "detached HEAD" state, how do you get into it, and what happens to commits you make there?

Accepted Answer

Normally HEAD points to a branch, and the branch points to a commit. In detached HEAD state, HEAD points directly at a commit. You get there by checking out a SHA, a tag or a remote-tracking branch (git checkout origin/main), and Git itself detaches HEAD during rebase and bisect. Many CI systems also check out a specific commit rather than a branch. It's perfectly fine for looking around, building an old version or testing. You can even commit, but no branch moves to include those commits. When you switch away, they're left unreachable; Git warns "you are leaving 1 commit behind" and prints the SHA. Eventually garbage collection deletes them. To keep the work, create a branch while you're still there, git switch -c name. If you already left, find the SHA in the warning or in git reflog and run git branch name <sha>.

Question 18

What is a commit internally? Explain blobs, trees, commits, refs and the SHA hash.

Accepted Answer

Git is a content-addressed object store. Every object is identified by a hash of its type, size and content: SHA-1 by default, with SHA-256 repositories available via git init --object-format=sha256. - Blob: the raw content of a file. No name, no permissions, so identical content is stored once. - Tree: a directory listing mapping names and modes to blobs and sub-trees. - Commit: a pointer to one root tree (a full snapshot of the project), zero or more parent commits, author, committer, timestamps and the message. - Annotated tag: an object pointing at a commit, with a tagger and message. Refs such as branches and tags are just human-friendly names that store a SHA. So a commit is a snapshot, not a diff; unchanged files reuse the same blob. Because a commit's hash covers its tree and its parents' hashes, changing anything in history changes every descendant's SHA. That's why rewriting history produces new commits and why a SHA identifies an exact state.

Question 19

Walk me through the stages of a typical CI/CD pipeline for a web service.

Accepted Answer

A typical pipeline, triggered by a push or pull request:

Build: check out the exact commit, install dependencies from the lockfile, compile.
Fast checks: lint, formatting, type checks and unit tests. Cheapest first, so failures surface in minutes.
Security scans: SAST on the code, dependency (SCA) scanning for vulnerable packages, secret scanning, and later container image and IaC scans.
Package the artifact: produce one immutable, versioned artifact, such as a container image tagged with the commit SHA, and push it to a registry.
Deploy to staging and run integration, end-to-end and smoke tests against it.
Approval (continuous delivery) or automatic promotion (continuous deployment).
Deploy to production progressively, canary or rolling, with health checks and automatic rollback.

Principles: fail fast, parallelise independent jobs, and build once, promote the same artifact through every environment instead of rebuilding, so what you tested is exactly what you ship.

Question 20

Explain the building blocks of a GitHub Actions workflow: triggers, jobs, steps and runners.

Accepted Answer

A workflow is a YAML file in .github/workflows/. - Triggers (on): events such as push, pull_request, workflow_dispatch (manual button), schedule (cron, UTC by default), release or workflow_call (reusable workflows). You can filter by branch, tag or path. - Jobs: units of work that run in parallel by default, each on its own runner. needs creates dependencies and ordering. Jobs don't share a filesystem, so you pass files between them with artifacts. - Runners: the machines that execute jobs, chosen by runs-on. GitHub-hosted runners (ubuntu-latest, windows-latest, macos-latest) give each job a fresh VM; self-hosted runners are your own machines. - Steps: run in order inside a job and share its workspace. A step either uses an action (reusable code like actions/checkout) with inputs in with, or runs shell commands. Other common keys: env, permissions for the GITHUB_TOKEN, strategy.matrix, environment and concurrency.

Question 21

You rebased a branch that is already pushed. How do you publish it safely, and why prefer --force-with-lease over --force?

Accepted Answer

After a rebase or amend, your local branch no longer contains the remote tip, so a normal push is rejected as non-fast-forward. You have to force it.

--force overwrites the remote branch with whatever you have, no questions asked. If a teammate pushed a commit since you last fetched, it silently disappears.

--force-with-lease only overwrites the remote ref if it still points where your remote-tracking branch says it does, the state you last saw. If someone pushed in the meantime, the push fails and you can fetch and incorporate their work. The caveat: if your IDE fetches in the background, your tracking ref is already updated and the lease protects nothing. --force-if-includes adds a check that the remote tip is actually in your local branch's history.

Team rules: only force-push your own feature branches, protect main so force pushes are blocked, and tell anyone else on the branch so they can reset onto the new history.

Question 22

How do you clean up a messy feature branch before opening a pull request?

Accepted Answer

With an interactive rebase: git rebase -i main (or HEAD~5) opens a todo list with one line per commit, oldest first. You edit the list and Git replays it: - pick keeps a commit, reword changes its message, edit stops so you can amend or split it. - squash melds a commit into the previous one and combines messages; fixup does the same but discards its message. - drop (or deleting the line) removes a commit; reordering lines reorders commits. - exec runs a command, for example the tests, after a commit. A nice workflow is to make corrections as git commit --fixup=<sha> while you work, then git rebase -i --autosquash main moves each fixup under its target automatically. If it goes wrong, git rebase --abort restores the branch, and the reflog has the old tip. Because it rewrites commits, do it only on your own branch, then publish with --force-with-lease.

Question 23

What is the difference between a lightweight and an annotated tag, and how do tags relate to releases?

Accepted Answer

A tag is a named ref to a specific commit that, unlike a branch, isn't supposed to move.

A lightweight tag is just a ref: a name that stores a commit SHA, nothing more.
An annotated tag (git tag -a) is a real object in the database with the tagger's name, a date and a message, and it can be signed (git tag -s). Use annotated tags for releases; tools treat them as the official ones. For example git describe uses only annotated tags unless you pass --tags, and git push --follow-tags pushes only annotated tags.

Tags aren't pushed with git push by default: push one explicitly or use --follow-tags.

A release on GitHub or GitLab is a platform feature built on top of a tag: release notes, a changelog and downloadable build assets. Treat published tags as immutable; moving a tag others have fetched causes confusion.

Question 24

What are remotes, remote-tracking branches and upstream branches? How do origin and upstream differ?

Accepted Answer

A remote is a named URL of another copy of the repository. git clone creates one called origin for the place you cloned from. In a fork workflow, people conventionally add upstream for the original project, so they pull from upstream and push to their fork, origin. The names are only conventions. A remote-tracking branch like origin/main is your local, read-only snapshot of where that branch was on the remote at your last fetch. You don't commit to it; git fetch updates it. A local branch can have an upstream (tracking) branch configured. That's what makes plain git pull and git push know where to go and lets git status report "ahead 2, behind 1". Set it with git push -u origin feature or git branch --set-upstream-to=origin/feature. git fetch --prune removes tracking refs for branches deleted on the remote.

Question 25

What is the difference between forking and cloning a repository? Describe the fork-based contribution workflow.

Accepted Answer

A clone is a Git operation: git clone copies a repository, with its full history, onto your machine. A fork is a hosting-platform feature: GitHub or GitLab creates a server-side copy of someone else's repository under your account, remembering which project it came from. Forks exist so you can contribute to a project you don't have write access to. The usual open-source workflow: - Fork the project, then clone your fork; it becomes origin. - Add the original project as a second remote, conventionally upstream. - Create a branch, commit, and push the branch to your fork. - Open a pull request from your fork's branch to the upstream repository. - Keep up to date by fetching upstream and rebasing or merging its main, or with the platform's "sync fork" button. Inside a company, where developers usually have write access, people normally skip forks and push branches to the shared repository.

Question 26

Compare rolling, blue-green and canary deployments. When would you use each?

Accepted Answer

Rolling: replace instances of the old version with the new one a few at a time, keeping the service up. It needs little extra capacity and is the default for a Kubernetes Deployment. The downsides: old and new versions serve traffic side by side for a while, and rolling back means rolling through all instances again. Blue-green: run two identical environments. Blue serves production while you deploy and test green; then you switch all traffic at the load balancer or DNS. Rollback is nearly instant: switch back. It costs double capacity during the switch, and the database must work with both versions. Canary: send a small slice of real traffic, say 1–5%, to the new version, compare error rates and latency with the baseline, then increase step by step, ideally with automated analysis that aborts on regression. It has the smallest blast radius, but needs traffic splitting and good observability. I'd default to rolling for low-risk services, canary for high-traffic, business-critical ones, and blue-green where instant cutover and rollback matter most.

Question 27

What makes a good pull request, and what are your code review best practices?

Accepted Answer

As the author: - Keep PRs small and focused: one logical change that can be reviewed in one sitting. Big PRs get rubber-stamped. - Write a clear description: why the change is needed, what it does, how you tested it, screenshots for UI, and a link to the ticket. - Review your own diff first, make sure CI is green, and mark it draft until it's ready. As the reviewer: - Respond promptly; waiting on review is a major source of lead time. - Focus on correctness, design, tests, security and readability. Leave style to linters and formatters. - Ask questions rather than issue orders, explain the reasoning, and label optional comments as nits so the author knows what blocks the merge. - Approve when the change improves the codebase, not only when it's perfect. Enforce the basics with branch protection: required reviews, required status checks, and CODEOWNERS for sensitive areas.

Question 28

What makes a good commit, and a good commit message?

Accepted Answer

A good commit is atomic: one logical change, complete on its own, with the tests passing. That makes history easy to review, revert, cherry-pick and bisect. Mixing a bug fix, a refactor and a formatting pass in one commit makes all of those harder. A good message: - A short summary line, conventionally around 50 characters, in the imperative mood: "Fix token refresh race", not "fixed stuff". It's what git log --oneline, PR lists and tools show. - A blank line, then a body, wrapped at about 72 characters, explaining why the change was needed and any trade-offs. The diff already shows *what* changed. - References to the issue or ticket, and a BREAKING CHANGE note if relevant. Many teams add a Conventional Commits prefix such as fix(auth): so changelogs and version bumps can be automated. Avoid "WIP" and "misc" commits on shared branches; clean them up with an interactive rebase or a squash merge.

Question 29

What do git diff, git diff --staged, git diff HEAD and git diff main...feature each show?

Accepted Answer

They compare different pairs of snapshots:

git diff: working tree against the index, so only changes you haven't staged.
git diff --staged (same as --cached): the index against HEAD, exactly what the next commit will contain.
git diff HEAD: working tree against the last commit, staged and unstaged together.
git diff main feature (or main..feature): the two tips directly. If main moved on, its new commits show up as reversed changes.
git diff main...feature: feature against the merge base of the two, which is only what the feature branch changed. That's what a pull request shows.

Handy flags: --stat or --name-only for a summary, --word-diff for prose, -w to ignore whitespace.

Careful: in git log, the dots mean something different. main..feature lists commits on feature not on main, and ... is the symmetric difference.

Question 30

Why were git switch and git restore added when git checkout already existed?

Accepted Answer

git checkout does two unrelated jobs: switching branches and overwriting files from the index or a commit. The same command name for both is confusing, and it's dangerous: git checkout -- file silently throws away your uncommitted changes, and git checkout name behaves differently depending on whether name is a branch or a file. Git 2.23 split it into two focused commands: - git switch only changes branches: -c creates one, - returns to the previous branch, --detach checks out a commit. - git restore only restores files: by default the working tree from the index, --staged to unstage, --source=<commit> to take a file from another commit. checkout still works and you'll see it everywhere in older docs and scripts, but switch and restore make intent explicit and are harder to misuse.

Question 31

How do you rename or delete a branch, locally and on the remote?

Accepted Answer

Renaming: git branch -m new-name renames the current branch, or git branch -m old new renames another one. Git has no "rename" on a remote, so you push the branch under the new name with git push -u origin new-name (which also updates the upstream) and delete the old remote branch. Open pull requests tied to the old name may need attention, and teammates must update their tracking branches. Deleting locally: git branch -d feature only succeeds if the branch is fully merged: into its upstream, or into the current branch if it has none. That safety check fails after a squash merge, because Git can't see the commits in main. git branch -D forces it; the commits are then reachable only through the reflog. Deleting on the remote: git push origin --delete feature. Other clones keep a stale origin/feature until they run git fetch --prune. Most platforms can delete the branch automatically after a PR is merged.

Question 32

A bug appeared somewhere in the last 300 commits. How would you find the commit that introduced it?

Accepted Answer

I'd use git bisect, which does a binary search through history. Mark a known bad commit and a known good one, and Git checks out the commit halfway between. You test it and mark it good or bad, and each answer halves the range, so 300 commits take about 9 steps. Better still, automate it with git bisect run <script>. The script's exit code drives the search: 0 means good, 1 to 127 (except 125) means bad, and 125 means "can't test this one, skip it", for example when the build is broken. Anything else aborts the run. A failing test written for the bug is the perfect script. git bisect skip handles untestable commits manually, and git bisect reset returns you to your original branch. You can also rename the terms, for example --term-old=fast --term-new=slow, when hunting a performance regression rather than a bug. Bisect works best when every commit builds and is small, which is one more argument for clean history.

Question 33

How do you find out who last changed a line and why? How do you stop a mass reformat from polluting git blame?

Accepted Answer

git blame file annotates every line with the commit, author and date that last changed it. -L narrows it to a line range, -w ignores whitespace-only changes, and -M / -C detect lines moved within a file or copied from other files. Blame tells you *which commit*; the useful part is then reading that commit with git show, its message and its pull request, to understand why. It's for context, not for blaming people. Large formatting commits make every line point at "run prettier". List such commits in a file, conventionally .git-blame-ignore-revs, and pass it with --ignore-revs-file or set blame.ignoreRevsFile so blame looks past them. GitHub's blame view honours a .git-blame-ignore-revs file in the repository root. When a line has been rewritten many times, git log -L shows the history of a line range, and git log -S finds commits that added or removed a string.

Question 34

A deployment broke production. How do you roll back, and how do you design a pipeline so rollbacks are easy?

Accepted Answer

First restore service, then fix properly. The fastest options, roughly in order: - Turn off the feature flag if the change was behind one: no deploy at all. - Redeploy the previous artifact. If every build produces an immutable, versioned artifact (an image tagged with the commit SHA), rollback is just deploying the last known-good version: switching blue-green back, aborting the canary, or kubectl rollout undo. - Then git revert the bad commit on main so the code matches what's running and the next deploy doesn't reintroduce the bug. Design for it: - Build once and keep previous artifacts in the registry. - Make database migrations backward compatible (expand and contract), so the old version can still run against the new schema. Irreversible migrations are what usually make rollback impossible. - Automate health checks so a failing canary or rollout stops and rolls back on its own. - Practise rollbacks; an untested rollback path fails when you need it. Sometimes rolling forward with a small fix is faster, but only if you're confident.

Question 35

How do you handle database schema changes in a continuous deployment pipeline without downtime?

Accepted Answer

The core problem is that during a rolling, blue-green or canary deployment, old and new application versions run at the same time against the same database, and you may need to roll the application back. So every migration must be compatible with both the current and the previous version.

The standard technique is expand and contract (parallel change). To rename a column:

Expand: add the new column, nullable. Deploy code that writes to both columns and reads the old one. Backfill existing rows in batches.
Migrate: deploy code that reads the new column.
Contract: once no running version uses the old column, drop it in a later release.

Other rules: never drop or rename in the same deploy as the code change; run migrations as a separate pipeline step with a versioned tool like Flyway, Liquibase or Alembic; avoid long table locks (for example, create indexes concurrently in PostgreSQL); and test against production-sized data. Rolling back usually means rolling the app back, not the schema, which is exactly why the schema must stay backward compatible.

Question 36

How do you handle secrets safely in a CI/CD pipeline?

Accepted Answer

- Never commit secrets. Keep them in the CI platform's secret store (repository, organisation or environment secrets in GitHub) or an external vault, and inject them at runtime through environment variables. - Prefer short-lived credentials. Use OIDC so the job exchanges a signed identity token for temporary cloud credentials instead of storing long-lived access keys. - Least privilege. Scope each secret to the job and environment that needs it, set the GITHUB_TOKEN permissions to read-only by default, and put production secrets behind an environment with required approval. - Don't leak them. Log masking is best-effort: a secret that's transformed (base64, JSON) may not be redacted, so never echo secrets or pass them as command-line arguments. - Untrusted code. Secrets aren't passed to workflows triggered from forks, and pull_request_target should never run a PR's untrusted code with secrets. Pin third-party actions to a full commit SHA. - Detect and rotate. Enable secret scanning and push protection, rotate regularly, and rotate immediately on any leak; deleting the commit isn't enough.

Question 37

How do matrix builds and dependency caching work in GitHub Actions?

Accepted Answer

A matrix runs the same job once per combination of variables. With two operating systems and two Node versions you get four parallel jobs, each reading its values from matrix.os and matrix.node. include adds or extends combinations, exclude removes some, and max-parallel limits concurrency. fail-fast defaults to true, which cancels the remaining jobs when one fails; set it to false when you want the full picture. A matrix can generate at most 256 jobs per workflow run. Caching saves directories like ~/.npm between runs. The key usually includes the OS and a hash of the lockfile, so a dependency change produces a new cache. On an exact key miss, restore-keys are tried as prefixes to restore the most recent close match, and the cache is saved under the new key at the end. Setup actions such as actions/setup-node offer this built in via cache: npm. Caches are scoped by branch (a branch can use its own and the default branch's), unused entries are evicted after 7 days, and you should never cache secrets.

Question 38

What are feature flags, and how do they enable trunk-based development and continuous deployment?

Accepted Answer

A feature flag is a runtime switch that turns a code path on or off without a new deployment, usually read from a flag service or config. Their key effect is to decouple deploying from releasing. Unfinished work can be merged into trunk every day behind a flag that's off, so there's no long-lived feature branch, and it deploys harmlessly with everything else. Releasing becomes a flag flip: to internal users first, then a percentage of customers, then everyone. If something goes wrong, turning the flag off is the fastest rollback there is. Common kinds: short-lived release toggles, ops toggles and kill switches, experiment toggles for A/B tests, and long-lived permission toggles. The costs are real: every flag doubles the code paths to test, and stale flags become technical debt, so give each one an owner and remove it once the rollout finishes. Define a safe default in case the flag service is unreachable.

Question 39

What are Conventional Commits, and how do they relate to semantic versioning?

Accepted Answer

Semantic versioning uses MAJOR.MINOR.PATCH: bump MAJOR for incompatible API changes, MINOR for backward-compatible features, and PATCH for backward-compatible bug fixes. Versions below 1.0.0 mean initial development, where anything may change. Pre-releases look like 2.0.0-rc.1 and sort before 2.0.0; build metadata after a + is ignored for precedence. Conventional Commits is a commit message convention: type(scope): description. feat maps to a MINOR bump, fix to a PATCH, and a breaking change, marked by ! before the colon or a BREAKING CHANGE: footer, maps to MAJOR. Other types such as docs, refactor, test, ci and chore are allowed and don't trigger a release on their own. Because the messages are machine-readable, tools can generate changelogs and compute the next version automatically, and they're easy to enforce with a commit-msg hook or a CI check.

Question 40

What are Git hooks, and how do you share pre-commit checks across a team?

Accepted Answer

Hooks are scripts Git runs at certain points. Client-side ones include pre-commit (lint and test before the commit is created), commit-msg (validate the message), pre-push, post-checkout and post-merge. Server-side hooks such as pre-receive run on the server during a push. For the pre- hooks, a non-zero exit aborts the operation.

By default they live in .git/hooks, which is not versioned or cloned, so every developer would have to install them manually. To share them:

commit a directory like .githooks and point core.hooksPath at it;
or use a hook manager such as the pre-commit framework, Husky or lefthook, which installs hooks from a committed config.

Keep hooks fast, for example by checking only staged files. And remember they're a convenience, not enforcement: git commit --no-verify skips pre-commit and commit-msg. Anything that really matters must also run in CI.

Question 41

Your CI has flaky tests that fail randomly. How do you deal with them?

Accepted Answer

A flaky test passes and fails on the same code. It's dangerous beyond the wasted time: people learn to hit "re-run" and stop trusting red builds, so real failures slip through. Detect: track test results over time, rerun failures to confirm flakiness, and measure a flake rate per test. Contain: quarantine known-flaky tests out of the blocking suite, with a ticket, an owner and a deadline, so they don't block everyone but aren't forgotten. Fix the root cause. The usual suspects: - timing: fixed sleeps instead of waiting for a condition - shared state or test order dependence - real network calls or external services - dates, time zones and unseeded randomness - concurrency and resource limits on the runner Automatic retries are fine as a short-term safety net, but they can hide real race conditions in the product. Treat flakiness as a bug with priority, because a pipeline nobody trusts is worse than none.

Question 42

What are the DORA metrics, and how would you use them?

Accepted Answer

DORA's research measures software delivery performance with a small set of metrics. The classic "four keys" are:

Deployment frequency: how often you deploy to production.
Lead time for changes: time from commit to running in production.
Change failure rate: share of deployments that need immediate intervention, such as a rollback or hotfix.
Time to restore: how quickly you recover, now framed as failed deployment recovery time.

Recent DORA guidance adds a fifth, deployment rework rate: unplanned deployments made because of a production incident. DORA groups them into throughput (frequency, lead time, recovery time) and instability (change failure rate, rework rate), and the key finding is that they aren't a trade-off: top performers are both fast and stable, because small, frequent changes are easier to test and roll back.

Use them at the team or service level to spot bottlenecks and track improvement, measured from version control, the pipeline and incident data. Don't use them to rank individuals or set targets to game.

Question 43

How would you add a manual approval gate before production deployments in GitHub Actions?

Accepted Answer

Use an environment. In the repository settings, create production and add deployment protection rules, then reference it from the job with environment: production. - Required reviewers: the job pauses until one of the listed people or teams approves. You can also prevent people from approving their own deployments. - Wait timer: delay the job for a set number of minutes after it's triggered. - Deployment branches and tags: only allow, say, main or v* tags to deploy there. - Custom protection rules can call external systems, such as a change-management check. Secrets stored on the environment are only available to jobs that reference it, and only after approval, so the production credentials are gated too. Add concurrency so two production deploys never overlap, and needs so production only runs after staging succeeds. Availability of some protection rules for private repositories depends on your GitHub plan. GitLab CI's equivalent is a job with environment, when: manual and protected environments.

Question 44

What is a build artifact, and how should artifacts and container images be stored and promoted?

Accepted Answer

An artifact is the output of a build that you deploy or distribute: a JAR, a binary, a zipped static site, an npm package or a container image. The core principle is build once, deploy many: the same artifact that passed the tests is promoted through staging and production, never rebuilt per environment. Environment differences belong in configuration. Artifacts live in a repository manager (Nexus, Artifactory, GitHub Packages, npm) and images in a container registry (GHCR, Docker Hub, Amazon ECR, Google Artifact Registry, GitLab's registry). Good practice: - Tag images immutably with the commit SHA and a version; don't deploy latest. For exactness, deploy by digest (@sha256:...). - Scan images for vulnerabilities, and consider signing them and publishing an SBOM. - Set retention policies, but keep enough old versions to roll back. Don't confuse this with CI workflow artifacts (actions/upload-artifact), which pass files between jobs and expire after a retention period; they're not a release registry.

Question 45

How do you revert a merge commit, and what happens when you later try to merge that branch again?

Accepted Answer

A merge commit has two parents, so git revert needs to know which side is the mainline: git revert -m 1 <merge> keeps the first parent, the branch you merged into, and undoes everything the merged branch brought in. Without -m, Git refuses. The gotcha is that a revert undoes the changes, not the history. The feature's commits are still ancestors of main, so Git considers them merged. If the team fixes the feature and merges the branch again, Git only brings in the commits made *after* the first merge. If there are none, it says "Already up to date", and the original work stays reverted. To re-land it, revert the revert first, which restores the original changes, then merge the new fixes. Alternatively rebuild the feature as fresh commits, for example by rebasing it onto current main so it gets new SHAs. This is why many teams prefer squash merges or feature flags: undoing a feature is simpler.

Question 46

How would you protect the main branch on GitHub or GitLab, and why not rely on local hooks?

Accepted Answer

Local hooks can be skipped with --no-verify or simply never installed, so rules that matter have to be enforced on the server. On GitHub that's branch protection rules or rulesets; on GitLab, protected branches and merge request approval rules. Typical settings for main: - Require a pull request before merging, with at least one or two approvals, and dismiss stale approvals when new commits are pushed. - Require review from CODEOWNERS for sensitive paths. - Require status checks to pass, such as build, tests and security scans, and optionally require the branch to be up to date with main, or use a merge queue so each change is tested against the latest main. - Block force pushes and deletion, optionally require linear history or signed commits, and require conversations to be resolved. - Apply the rules to administrators too, with a documented break-glass path. Together these make "main is always green and reviewed" a guarantee instead of a hope.

Question 47

Why are large binary files a problem in Git, and how does Git LFS help?

Accepted Answer

Git keeps every version of every file forever, and every clone downloads the full history. Binaries such as images, videos, datasets or compiled builds don't diff or compress well, so each change adds roughly the full file size. The repository gets permanently slower to clone and fetch, and GitHub warns above 50 MiB and blocks files over 100 MiB. Git LFS (Large File Storage) replaces large files in the repository with small pointer files containing the object's SHA-256 and size. The real content lives on an LFS server and is downloaded only for the commits you check out. You choose files by pattern with git lfs track, which writes rules to .gitattributes; commit that file. Things to know: files already committed stay in history until you rewrite it with git lfs migrate import; hosts have LFS storage and bandwidth quotas; CI checkouts must fetch LFS content (for example lfs: true on actions/checkout); and git lfs lock helps with files that can't be merged. Build outputs belong in an artifact store, not in Git at all.

Question 48

Someone pushed an API key to a public repository. What do you do?

Accepted Answer

First, revoke or rotate the key immediately. Assume it's compromised: automated scanners pick up secrets on public repositories within minutes, and removing the commit doesn't un-leak it. Check the provider's logs for misuse. Only then clean up history, if it's worth it: - A new commit deleting the file isn't enough; the key is still in history. - Rewrite history with git filter-repo, which Git's own documentation recommends over git filter-branch, or a tool like BFG: remove the file with --invert-paths --path, or replace the string with --replace-text. - Force-push every rewritten branch and tag, and have collaborators re-clone. An old clone that pushes again reintroduces the secret. - Forks and hosting-side caches, such as old pull request refs and views, can keep the data; on GitHub you contact Support to purge them. Then prevent a repeat: .gitignore the file, load secrets from environment or a vault, and enable secret scanning with push protection or a pre-commit scanner.

Question 49

Monorepo or polyrepo? What are the trade-offs, and how do you keep a large monorepo fast?

Accepted Answer

Monorepo: many projects in one repository. - Pros: atomic changes across services and shared libraries in one PR, one version of each dependency, shared tooling and CI, easy large-scale refactoring and code discovery. - Cons: Git and CI must scale. Clones and git status get slow, every PR could trigger every build, and access control is coarse. Polyrepo: one repository per service or library. - Pros: clear ownership, independent versioning and release cadence, fine-grained permissions, small fast repos. - Cons: cross-cutting changes need coordinated PRs and version bumps across repos, dependencies drift, and tooling gets duplicated. Keeping a monorepo fast: partial clone (--filter=blob:none) and sparse checkout so developers only materialise what they work on; build tools that understand the dependency graph and run only affected builds and tests (Bazel, Nx, Turborepo), or CI path filters; and CODEOWNERS for ownership. The deciding factor is coupling: tightly coupled code that changes together favours a monorepo.

Question 50

How do Git submodules differ from subtrees? When would you use each?

Accepted Answer

A submodule embeds another repository as a pointer: the parent records a special tree entry (a gitlink) with the exact commit SHA of the child, plus its URL in .gitmodules. The child's files aren't stored in the parent. That gives exact pinning and independent history, but it's easy to get wrong: a plain clone leaves the directory empty until you run git submodule update --init --recursive (or clone with --recurse-submodules), the submodule sits in detached HEAD, and forgetting to push the child's commit breaks everyone's checkout. A subtree copies the other project's files, optionally with its history squashed, into a subdirectory as ordinary commits. Clones just work and contributors need no extra commands; git subtree pull brings in upstream updates and git subtree push can send changes back. The cost is a bigger repo and manual syncing. git subtree ships in Git's contrib area, so check it's installed. I'd use submodules for a large external dependency with its own release cycle, and subtrees when vendoring something small that consumers shouldn't have to think about. Often a package manager beats both.

Git & CI/CD interview questions & answers

Top 58 Git & CI/CD interview questions most asked first