Question 1

What is Git, and why is it important for DevOps teams?

Accepted Answer

Git is a distributed version control system that tracks changes in code and other text-based files over time. It allows teams to collaborate safely, review changes, and maintain a reliable history of what was changed and why.

For DevOps teams, Git is not only for application code. It is also used for infrastructure as code, pipeline definitions, Kubernetes manifests, and operational configuration. That makes it central to automation, traceability, and rollback.

Question 2

What is the difference between `git fetch` and `git pull`?

Accepted Answer

`git fetch` downloads updates from a remote repository without changing your current branch. `git pull` downloads updates and then integrates them into your current branch, usually by merge or rebase.

This matters because `fetch` is safer when you want to inspect changes first, while `pull` is more convenient when you are ready to update your working branch immediately.

Question 3

What is the difference between `git merge` and `git rebase`?

Accepted Answer

`git merge` combines histories and usually creates a merge commit, preserving the exact branch structure. `git rebase` reapplies commits on top of a new base, creating a more linear history.

Neither is universally “better.” Merge preserves historical context, while rebase can make history cleaner. A strong answer should mention that rebasing shared public branches can cause problems because it rewrites commit history.

Question 4

When should you avoid rebasing?

Accepted Answer

You should avoid rebasing branches that other people are already using or depending on, because rebasing changes commit hashes and can disrupt collaboration.

Rebase is usually safer on local feature branches before they are widely shared. Once history is public, `merge` or `revert` is often the better choice.

Question 5

What is a pull request or merge request used for?

Accepted Answer

A pull request is a workflow for proposing changes, reviewing code, discussing design decisions, and validating quality checks before merging into a shared branch.

It improves collaboration because it creates a structured checkpoint for feedback, testing, and documentation. For DevOps work, it is especially valuable because infrastructure and pipeline changes can carry production risk.

Question 6

What is a detached HEAD state?

Accepted Answer

A detached HEAD state means Git is pointing directly at a specific commit instead of a named branch.

This is not always bad, but it becomes risky if you make commits there and forget to create a branch, because those commits can later become harder to find. A strong answer should mention that you can recover by creating a new branch from that state.

Question 7

How do you undo the last commit safely?

Accepted Answer

If the commit has already been shared, `git revert` is the safest choice because it creates a new commit that undoes the previous one without rewriting history.

If the commit is local and unpushed, you can use `git reset --soft HEAD~1` or another reset mode depending on whether you want to keep the changes staged, unstaged, or discard them. The right answer depends on whether history is shared.

Question 8

What does `git reflog` help with?

Accepted Answer

`git reflog` shows the local history of where HEAD and branch references have pointed. It is extremely useful for recovering commits after mistakes like resets, rebases, or accidental checkouts.

Many people know basic Git commands but forget `reflog` during recovery. Mentioning it in interviews often signals real practical Git experience.

Question 9

How do you resolve merge conflicts effectively?

Accepted Answer

First, understand the intent of both sides of the conflict rather than just removing conflict markers quickly. Then edit the file carefully, run tests, and verify that the final result preserves correct behavior.

Good conflict resolution is not just mechanical. The goal is to merge logic safely, especially when configuration, infrastructure code, or deployment behavior is involved.

Question 10

What is cherry-pick used for?

Accepted Answer

`git cherry-pick` applies a specific commit from one branch onto another. It is useful for backporting a hotfix or selectively moving a change without merging an entire branch.

It should be used thoughtfully because repeated cherry-picking can make history harder to follow if overused. Still, it is a very practical tool for release and support workflows.

Question 11

Why are protected branches useful in team workflows?

Accepted Answer

Protected branches help enforce guardrails such as required reviews, status checks, linear history rules, and restrictions on direct pushes.

They reduce the chance that unreviewed or failing code is merged into important branches like `main`. In DevOps-heavy repositories, this is especially valuable because the same repo may control infrastructure or deployment behavior.

Question 12

What makes a healthy Git workflow for teams?

Accepted Answer

A healthy workflow uses clear branching conventions, small reviewable changes, reliable CI, consistent commit hygiene, and safe merge practices.

The exact branching strategy can vary, but the main goal is to help teams collaborate without confusion, reduce merge pain, and keep releases traceable. Good Git workflow is really about reducing coordination risk.

Question 13

What is the difference between staged and unstaged changes?

Accepted Answer

Staged changes are the edits you have added to the index and plan to include in the next commit. Unstaged changes exist in the working tree but are not yet included in the next commit.

This matters because Git gives you fine-grained control over what goes into each commit. Good commit hygiene depends on understanding that distinction.

Question 14

Why are small commits useful?

Accepted Answer

Small commits are easier to review, easier to understand, and easier to revert if something goes wrong.

They improve collaboration because each commit tells a clearer story. This is especially helpful in infrastructure and DevOps repositories where one mistaken change can have broad impact.

Question 15

What is the difference between `git revert` and `git reset`?

Accepted Answer

`git revert` creates a new commit that undoes an earlier commit, while `git reset` moves the branch pointer and can rewrite local history.

This is an important safety distinction. `revert` is usually safer for shared history, whereas `reset` is more commonly used for local cleanup before changes are pushed.

Question 16

What does `git stash` do?

Accepted Answer

`git stash` temporarily saves uncommitted changes so you can switch context without committing incomplete work.

It is useful, but it should not become a long-term storage strategy. Strong answers may mention that branches are often a safer place for work you need to keep clearly.

Question 17

What is the purpose of `.gitignore`?

Accepted Answer

`.gitignore` defines files or patterns Git should not track, such as build outputs, local secrets, editor files, or generated caches.

This keeps repositories cleaner and reduces accidental commits of noise or sensitive content. Good answers also note that `.gitignore` does not untrack files already committed.

Question 18

What is a fast-forward merge?

Accepted Answer

A fast-forward merge happens when the target branch has not diverged, so Git can simply move the branch pointer forward without creating a merge commit.

It keeps history simpler in straightforward cases. Whether teams prefer it depends on how much they want explicit merge structure preserved.

Question 19

What is squash merging?

Accepted Answer

Squash merging combines all commits from a branch into one commit when merging into the target branch.

This can keep mainline history cleaner, especially for noisy feature branches, but it also hides the original branch commit structure. It is a tradeoff between simplicity and detail.

Question 20

Why are branch naming conventions helpful?

Accepted Answer

Consistent branch naming helps teams quickly understand the purpose of a branch, such as feature work, fixes, or releases.

Naming conventions improve automation, readability, and coordination, especially in larger teams with many active branches and CI workflows.

Question 21

What makes a good commit message?

Accepted Answer

A good commit message explains what changed and, when useful, why it changed. It should be clear enough that someone reading history later can understand the intent.

This matters because Git history is a shared communication tool, not just a storage mechanism. Better history makes debugging and review easier.

Question 22

How do release branches fit into Git workflows?

Accepted Answer

Release branches can be used to stabilize a version while ongoing development continues elsewhere. They are often useful when teams need controlled patching or support multiple release lines.

However, they also add complexity. Strong answers mention that the right workflow depends on team size, release cadence, and product needs.

Question 23

What is a fork-based workflow?

Accepted Answer

A fork-based workflow has contributors work from personal copies of a repository and submit changes back through pull requests.

It is common in open source and some enterprise setups because it provides stronger separation and access control. It also changes how remotes and collaboration are managed.

Question 24

How do you recover work after an accidental rebase or reset?

Accepted Answer

I would use `git reflog` to locate the prior branch or commit state, then create a branch or reset back to the correct point carefully.

This question often separates theoretical Git knowledge from practical experience. Recovery is one of the most valuable real-world Git skills.

Question 25

Why is CI integration important in Git workflows?

Accepted Answer

CI turns repository events like pushes and pull requests into automated validation signals, helping teams catch issues before merge or release.

Git and CI work best together. Source control without automated checks still leaves a lot of risk in team collaboration.

Question 26

How do you handle a large long-lived branch that is drifting from main?

Accepted Answer

I would try to reduce the branch lifetime, integrate changes from main more frequently, and break the work into smaller deliverable pieces if possible.

Long-lived divergence increases conflict risk and reduces delivery confidence. Strong answers show a preference for smaller, more incremental integration.

Question 27

What is GitOps at a high level?

Accepted Answer

GitOps is an operational model where desired system state, especially infrastructure or Kubernetes state, is declared in Git and reconciled automatically by tooling.

This makes Git workflows even more important in operations because merges to a repository can directly drive environment changes. It increases the need for clear review and disciplined branching.

Question 28

Why is branch protection especially important in GitOps repositories?

Accepted Answer

In GitOps, a merge can directly affect infrastructure or production state, so branch protection helps prevent risky or unreviewed changes from being applied automatically.

This raises the importance of code review, CI checks, and controlled access even further than in an application-only repository.

Question 29

What is the benefit of using pull requests for infrastructure changes?

Accepted Answer

Pull requests provide review, discussion, audit history, and automated validation before high-impact operational changes are merged.

They reduce the chance of unsafe infrastructure modifications and help teams collaborate on risky changes more deliberately.

Question 30

How do you keep Git history understandable over time?

Accepted Answer

I would favor clear commit messages, smaller focused changes, sensible merge strategy, and regular cleanup of confusing or overly large branches.

Readable history becomes extremely valuable during debugging, incident review, and long-term maintenance. It is part of operational quality, not just developer preference.

Git, Branching & Collaboration

1. What is Git, and why is it important for DevOps teams?

2. What is the difference between `git fetch` and `git pull`?

3. What is the difference between `git merge` and `git rebase`?

4. When should you avoid rebasing?

5. What is a pull request or merge request used for?

6. What is a detached HEAD state?

7. How do you undo the last commit safely?

8. What does `git reflog` help with?

9. How do you resolve merge conflicts effectively?

10. What is cherry-pick used for?

11. Why are protected branches useful in team workflows?

12. What makes a healthy Git workflow for teams?

13. What is the difference between staged and unstaged changes?

14. Why are small commits useful?

15. What is the difference between `git revert` and `git reset`?

16. What does `git stash` do?

17. What is the purpose of `.gitignore`?

18. What is a fast-forward merge?

19. What is squash merging?

20. Why are branch naming conventions helpful?

21. What makes a good commit message?

22. How do release branches fit into Git workflows?

23. What is a fork-based workflow?

24. How do you recover work after an accidental rebase or reset?

25. Why is CI integration important in Git workflows?

26. How do you handle a large long-lived branch that is drifting from main?

27. What is GitOps at a high level?

28. Why is branch protection especially important in GitOps repositories?

29. What is the benefit of using pull requests for infrastructure changes?

30. How do you keep Git history understandable over time?