Cloud DevOps Interview Guide – Git Q&A

Overview

Git is a distributed version control system that tracks changes in source code and enables collaboration among developers.
Every DevOps engineer is expected to master Git — it’s the foundation of CI/CD pipelines and modern software collaboration.

With Git, engineers can:

• Version and roll back code safely.
•  Collaborate through branches and pull requests.
•  Automate deployments directly from repositories (e.g., GitHub → Jenkins → AWS).

Common platforms: GitHub, GitLab, Bitbucket, AWS CodeCommit.

---

Beginner-Level Git Interview Questions (Fundamentals)

---

1. What is Git, and how is it different from GitHub?

Answer:

•   Git is a distributed version control tool that tracks changes to source code.

  GitHub is a cloud-based platform built on top of Git that provides hosting for repositories, collaboration tools, and features like pull requests and issue tracking.

In DevOps:
Git is installed locally to manage code, while GitHub or GitLab acts as a remote central repository for team collaboration and integration into CI/CD pipelines.

---

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

Answer:

•  git clone: Creates a copy of a remote repository on your local machine (used the first time you set up).
•  git fetch: Downloads changes from the remote repository but does not merge them into your local branch.
•  git pull: Fetches and automatically merges remote changes into your current branch.

Example in DevOps:
In CI/CD jobs, Jenkins often uses git fetch to check for changes before triggering a build.

---

3. How do you stage and commit changes in Git?

Answer:
After editing files, you must stage and commit them.

Staging allows you to prepare specific files for the next commit, while committing saves the changes to the local repository history.

---

4. What are branches in Git, and why are they important?

Answer:
A branch is an independent line of development that allows multiple developers to work in parallel.

• main (or master) → stable production code
• feature/login → feature under development
• bugfix/payment → bug fix branch

Commands:

In DevOps:
Branches isolate development work from production code — crucial for automated deployments and version control in CI/CD.

---

5. How do you view the commit history?

Answer:

Shows all commits with author, date, and message.
For a concise view:

Why it’s important:
Understanding commit history helps during troubleshooting, audits, and rollback planning in production environments.

---

6. What is .gitignore and why is it used?

Answer:
A .gitignore file tells Git which files or folders to exclude from version control.

Example:

Use in DevOps:
This prevents unnecessary or sensitive files (API keys, environment variables, binaries) from being uploaded to repositories — a crucial security practice.

---

7. How do you check the current branch and status of your repository?

Answer:

Displays:

• Current branch name
• Staged, unstaged, and untracked files

Example output:

---

8. What is the difference between git merge and git rebase?

Answer:

• git merge combines changes from one branch into another and preserves both commit histories.
• git rebase integrates changes by rewriting commit history to make it linear.

Example:

In CI/CD:
Teams use rebase to keep commit history clean and merge to maintain a detailed history of collaboration.

---

9. How do you undo the last commit in Git?

Answer:
If you haven’t pushed yet:

This removes the last commit but keeps changes staged.
To completely discard:

DevOps tip:
Use reset carefully — it rewrites commit history, which can affect team synchronization.

---

10. What’s the difference between git stash and git commit?

Answer:

• git stash: Temporarily saves uncommitted changes without committing them.
• git commit: Permanently records changes in history.

Example:

Use case:
During a deployment fix, you might stash local changes to quickly switch branches and return later without losing work.

---

Intermediate-Level Git Interview Questions (Real-World & Team Context)

---

1. What’s a pull request (PR), and why is it important in CI/CD pipelines?

Answer:
A Pull Request (PR) is a request to merge code from one branch (usually feature) into another (like main).

It includes:

• Code review
• Automated tests
• Security scans (e.g., GitHub Actions or Jenkins pipelines)

Why it matters:
Pull requests ensure that only reviewed, tested, and approved code reaches production — critical for stable releases.

---

2. How do you resolve merge conflicts in Git?

Answer:
A merge conflict happens when two branches modify the same part of a file differently.

Steps to resolve:

1. Git marks conflict areas like:

   <<<<<<< HEAD
print("Hello from main")
=======
print("Hello from feature")
>>>>>>> feature


2. Manually edit to keep the correct version.

3. Stage and commit:

   git add filename
git commit -m "Resolved merge conflict"


DevOps scenario:
Merge conflicts often occur when multiple developers push config files or Jenkinsfiles simultaneously.

---

3. What is the difference between origin and upstream?

Answer:

• origin: The default alias for the remote repository you cloned.
• upstream: The original repository (commonly used when you fork a repo).

Example:

Use in DevOps:
Helps when contributing to open-source or managing internal forks for enterprise CI/CD projects.

---

4. How do you tag a specific version of code in Git?

Answer:
Tags are used to mark important points in history (e.g., production releases).

Example:

Why it’s important:
Tags integrate with CI/CD tools (like Jenkins or CodePipeline) to trigger deployments for specific versions.

---

5. How do you revert a commit that’s already pushed to the remote repository?

Answer:
Use:

This creates a new commit that undoes the changes without rewriting history.

In DevOps:
This is preferred over reset for production repos because it’s safe and traceable.

---

6. What is a Git branching strategy? Name a few examples.

Answer:
A branching strategy defines how teams manage branches for features, releases, and hotfixes.

Common strategies:

• GitFlow:
  Uses branches for develop, feature, release, and hotfix.
  Ideal for large, structured teams.
• GitHub Flow:
  Lightweight; developers branch from main, open PRs, and merge after review.
• Trunk-Based Development:
  Everyone commits to a single branch (main) with frequent merges.

Why it matters:
Branching strategy impacts CI/CD efficiency and release management discipline.

---

7. How do you use Git in an automated CI/CD pipeline?

Answer:

1. Jenkins or GitHub Actions clones the repository:

   git clone https://github.com/org/app.git


2. Pulls the latest code (git pull) on each build.

3. Checks out a branch for deployment:

   git checkout main


4. Triggers build, test, and deploy stages automatically.

Benefit:
Git ensures source of truth consistency — pipelines deploy exactly what’s versioned in the repository.

---

8. How do you compare changes between two commits or branches?

Answer:

or between branches:

In CI/CD:
Used in pre-deployment scripts to identify which files changed since the last deployment (useful for incremental updates).

---

9. How do you delete a branch locally and remotely?

Answer:

• Local:

• Remote:

Why it matters:
Cleaning up branches prevents clutter and confusion in large-scale team projects.

---

10. How do you handle sensitive data or credentials in Git repositories?

Answer:
Never commit secrets directly!
Use:

• .gitignore to exclude .env or config files.
• Environment variables in CI/CD pipelines.
• Secret management tools like AWS Secrets Manager, HashiCorp Vault, or GitHub Secrets.

Example:
Instead of hardcoding credentials in a script:

---

Advanced-Level Git Interview Questions (Troubleshooting, CI/CD & Scenarios)

---

1. How do you perform a rollback in Git after a faulty deployment?

Answer:
If a deployment introduced a bug:

1. Identify the last stable commit:

   git log --oneline


2. Revert to that commit:

   git revert <commit_id>


3. Push the revert commit and redeploy:

   git push origin main


DevOps workflow:
Rollback scripts in pipelines often automate this process to restore system stability quickly.

---

2. How do you squash commits, and why would you do it?

Answer:
Squashing merges multiple commits into one to simplify history.

Example:

Replace pick with squash for the commits you want to combine.

When used:
Before merging a feature branch to main, squash commits to keep history clean — especially in enterprise CI/CD environments.

---

3. What’s the difference between git cherry-pick and git revert?

Answer:

• git cherry-pick: Copies a commit from one branch to another.
  Example: Apply a hotfix from main to develop.
• git revert: Creates a new commit that undoes changes from a previous commit.

In DevOps:
Useful for emergency patching or backporting critical changes.

---

4. How do you set up Git hooks, and why are they useful?

Answer:
Git hooks are scripts that automatically run when certain Git events occur (like commit or push).

Located in .git/hooks/.
Example: pre-commit, post-commit, pre-push.

Example use:

Prevents committing if tests fail.

In CI/CD:
Hooks are used to enforce quality gates (linting, tests) before merging code.

---

5. How do you clean up large or sensitive files accidentally pushed to Git history?

Answer:
Use BFG Repo-Cleaner or git filter-branch.
Example:

Then force-push cleaned history:

DevOps impact:
Accidentally committing secrets can expose credentials in CI/CD logs — cleaning history is part of secure repository hygiene.

---

6. What’s the difference between git reset, git revert, and git restore?

Answer:

Example:

Undo local changes without touching commits.

---

7. How do you integrate Git with Jenkins for CI/CD automation


Answer:

• Configure Jenkins to use the Git plugin.
• In Jenkinsfile:
• pipeline {
stages {
stage('Checkout') {
steps {
git branch: 'main', url: 'https://github.com/cloudnukes/project.git'
}
}
stage('Build') {
steps {
sh 'npm install'
}
}
}
}
• Benefit:
  Ensures Jenkins always builds from the latest Git code and triggers builds automatically on new commits.

---

• 8. How do you perform a code review effectively using Git tools?
• Answer:
  Code reviews typically happen in GitHub/GitLab through Pull Requests.
• Checklist:
• Ensure proper branching strategy.
• Validate commit messages follow convention.
• Review CI pipeline results.
• Check for security issues in diffs.
• Add comments inline using GitHub review tools.
• DevOps note:
  Automated review gates can be added (e.g., tests, code coverage, linting) before approval.

---

• 9. (Scenario – STAR Format)
• Q: Your team accidentally merged a faulty feature branch into main, breaking the production pipeline. What did you do?
• Answer (STAR):
• Situation:
  A faulty feature was merged into main, triggering failed builds and downtime on staging.
• Task:
  Identify the bad commit and restore stability.

• Action:

  1. Used git log to find the merge commit.

  2. Ran git revert -m 1 <merge_commit_id> to undo the merge safely.

  3. Pushed the fix and re-triggered the Jenkins build.

  4. Opened a follow-up PR with corrected code after testing.

• Result:
  Production was restored within 10 minutes, with no rollback required. The team later enforced branch protection rules to prevent unreviewed merges.

---

• 10. (Scenario – STAR Format)
• Q: During a deployment, you realized a teammate accidentally pushed secrets to GitHub. What steps did you take to mitigate the risk?
• Answer (STAR):

• Situation:
  During a Jenkins deployment, we found AWS credentials hardcoded in a committed config file pushed to GitHub.

• Task:
  Remove the secrets immediately and secure the environment.

• Action:
• Rotated the exposed AWS access keys.
• Removed the file and used bfg --delete-files "*.env" to clean Git history.
• Force-pushed the sanitized repo.
• Added .env to .gitignore.
• Moved all secrets to AWS Secrets Manager and referenced them as environment variables.
• Result:
  Breach risk eliminated, repository cleaned, and pipeline hardened with secret scanning tools (like truffleHog) to prevent recurrence.