Git Version Control Interview Questions and Answer

1. What is Git?

Git is a distributed version control system that tracks changes in source code and allows multiple developers to work on the same project without overwriting each other’s work.

2. How is Git different from GitHub?

Git is the tool used for version control on your local machine, while GitHub is a cloud platform that hosts Git repositories and provides collaboration features like pull requests, issues, CI/CD, and code reviews.

Example (if required):

• Git = MS Word (the tool)
• GitHub = Google Drive (where the file is stored and shared)

3. What is Version Control? Why do we need it?

Version Control is a system that tracks changes made to files over time, allowing you to restore previous versions, compare changes, and collaborate safely. We need version control to avoid losing work, track history, work collaboratively, and manage multiple versions of code without conflicts. It ensures safe, organized, and traceable development across teams.

4. What is a repository?

A repository is a storage location where your project’s files and their complete version history are kept. It can be local on your machine or remote on platforms like GitHub.

5. Difference between local repo and remote repo.

A local repository exists on your machine where you create, edit, and commit code.
A remote repository is hosted on a server like GitHub, GitLab, or Bitbucket and is used for sharing code and collaborating with others.

In simple terms:

• Local repo = your personal copy
• Remote repo = shared team copy

6. What is git init?

git init is a fundamental Git command that initializes a new Git repository. This action transforms a standard directory into a Git-managed project, enabling version control.

When git init is executed within a directory, it performs the following:

• Creates a .git subdirectory: This hidden folder is the core of the Git repository. It contains all the necessary metadata for Git to track changes, including object databases, references (branches and tags), configuration files, and other internal structures.
• Prepares for version control: The presence of the .git directory allows Git commands like git add, git commit, git branch, and others to function within that directory and its subdirectories.
• Initializes a default branch: Typically, a default branch (often named main or master) is created that points to the repository's initial state.

Example: If you create a new project from scratch, the first step is often

git init

7. What does git clone do?

git clone is used to create a full local copy of a remote Git repository, including all files, commit history, branches, and tags. It essentially downloads the project from platforms like GitHub or GitLab to your machine so you can start working on it.

When you run:

git clone <repository-url>

Git creates a new folder, pulls all the project data, and automatically sets the remote name as origin, allowing you to sync changes later using git pull and git push.

In short, git clone is used when you want to start working on an existing project hosted remotely.

8. What is the difference between git clone and git pull?

git clone is used once to create a complete local copy of a remote repository.

It downloads everything, files, commit history, branches, and sets up the connection to the remote.

Use case: When you're starting with a project for the first time.

git pull is used after you have cloned the repository, to get the latest changes from the remote repository into your existing local repo.

It performs:

• git fetch (downloads changes)
• git merge (merges them into your current branch)

Use case: To keep your local copy updated with the team’s latest changes.

9. What is a commit?

A commit in Git is a snapshot of your project’s files at a specific point in time.
Whenever you make changes and run git commit, Git records:

• The exact state of your files
• Who made the change
• When it was made
• A message describing why the change was made

Commits form the history of your project, allowing you to go back to earlier versions, compare changes, and understand how the code evolved.

Each commit has a unique SHA-1 hash, which acts like an ID for that snapshot.

10. What is the staging area in Git?

The staging area (also called the index) is a place where Git collects and organizes your changes before creating a commit.

When you modify files, they don’t go directly into a commit.
You first add them to the staging area using:

git add <file>

This step allows you to:

• Choose which changes you want to include in the next commit
• Group related changes together
• Avoid committing accidental or incomplete changes

The staging area acts as a buffer between your working directory and the final commit.
It gives developers control and ensures each commit is clean, meaningful, and intentional.

11. Explain the Git file lifecycle (untracked → tracked → staged → committed).

1. Untracked

A file is untracked when it exists in your project folder, but Git is not monitoring it yet. These are usually new files you just created.

Example: You create login.js → Git doesn’t know about it yet.

2. Tracked

A file becomes tracked as soon as you add it to Git using:

git add <file>

Tracked means Git is aware of the file and will monitor its future changes.
Tracked files can be unmodified, modified, or staged.

3. Staged (Index)

A staged file is one whose latest changes are prepared for the next commit.

When you run git add <file>, the file is moved from modified → staged.

This allows you to control exactly which changes will go into the next commit.

4. Committed

When you run:

git commit -m "message"

all staged changes are saved into Git’s repository history.

A commit represents a permanent snapshot that you can revert to or compare later.

Simple Summary

• Untracked: Git doesn’t know about the file.
• Tracked: Git knows the file exists.
• Staged: File is ready to be committed.
• Committed: File changes are permanently stored in Git history.

This lifecycle ensures clean, controlled, and well-organized version management.

12. What do git add . and git add -A do?

Both commands are used to move changes from the working directory to → staging area, but they behave slightly differently.

git add .

This command stages:

• New files
• Modified files

within the current directory and its subdirectories.

But it does NOT stage deleted files.

Example: If you delete a file, git add . will ignore that deletion.

git add -A

This command stages all changes in the entire repository, including:

• New files
• Modified files
• Deleted files

It ensures your staging area represents the exact state of your working directory.

Simple Difference

• git add . → add new + modified files (no deletions)
• git add -A → add new + modified + deleted files (complete sync)

Most developers use git add -A when preparing a clean commit.

13. What does git status show?

git status gives a clear summary of the current state of your working directory and staging area.

It helps you understand what Git sees before you commit.

1. Untracked files: Files Git is not tracking yet (new files).

2. Modified files: Files that have been changed but are NOT staged.

3. Staged files: Files that are added to the staging area and will be included in the next commit.

4. Branch information: It shows which branch you're currently on and whether your branch is ahead/behind the remote.

5. Instructions/help: It often suggests next steps, like:

• “Use git add to stage changes.”
• “Use git restore to discard.”

14. What does git log do?

git log displays the history of commits in your repository.

It shows each commit in reverse chronological order (newest first), along with important details like:

• Commit hash (SHA) → unique ID of the commit
• Author → who made the commit
• Date → when the commit was made
• Commit message → why the change was made

Example:

commit 8f3a2c...
Author: John Doe
Date:   Tue Dec 2

    Added login validation

15. What is .gitignore? Why is it used?

.gitignore is a special configuration file in a Git project that tells Git which files or folders it should completely ignore.

Files listed inside .gitignore will not be tracked, not appear in git status, and won’t be added to commits, even if they exist in your project directory.

It is used to keep your repository clean and free from files that should not be version-controlled, such as:

• Temporary or cache files (e.g., dist/, temp/)
• Build outputs and compiled code (bin/, obj/)
• Dependency folders (e.g., node_modules/)
• Sensitive files (API keys, credentials)
• IDE/system-specific files (.vscode/, .DS_Store)

Using .gitignore prevents unnecessary or private files from being committed, reducing repo size and avoiding security risks.

16. How to remove a file from Git but keep it locally?

To remove a file from Git’s tracking without deleting it from your local system, you use:

git rm --cached <file>

This command removes the file from the staging/index, meaning Git will no longer track its changes, but the file itself remains in your working directory.

After running this, you commit the change:

git commit -m "Stop tracking file"

If it's a file you never want Git to track again, add it to .gitignore.

17. What is a branch in Git?

A branch in Git is a separate line of development that allows you to work on new features, bug fixes, or experiments without affecting the main codebase.

When you create a branch, Git simply creates a new pointer to a commit. It doesn’t copy the entire project, so branching is very fast and lightweight.

Developers commonly use branches to isolate work:

• main or master → stable production-ready code
• feature/login → new login feature
• bugfix/payment → fix for payment issue

Once the work is complete, the branch can be merged back into the main branch through a merge or pull request.

18. How to create a branch?

Use git branch <name> to create a branch, and git switch -c <name> to create and start working on it immediately.

19. Difference between git merge and git rebase.

git merge and git rebase both integrate changes from one branch into another, but they do it in very different ways, affecting your project history.

• git merge: When you merge a branch, Git combines the commit histories of two branches and creates a merge commit.
• git rebase: Rebase takes your commits and reapplies them on top of another branch, as if you created them from there originally.

In short:

• Merge preserves history; Rebase rewrites it.
• Merge is safer for collaboration; Rebase is best for clean, linear commits.

20. What is a merge conflict?

A merge conflict happens when Git is unable to automatically combine changes from two branches because both branches modified the same part of the same file, or one branch deleted something that the other branch edited.

Git doesn’t know which version is correct, so it stops the merge and asks the developer to resolve it manually.

During a merge conflict, Git marks the conflicting sections in the file using:

<<<<<< HEAD
Your changes
======
Other branch changes
>>>>>> branch-name

21. What is a detached HEAD state?

A detached HEAD state happens when your HEAD pointer (which normally points to the latest commit of a branch) points directly to a specific commit, tag, or old revision instead of a branch.

In this state, you are not on any branch.
You are simply viewing or modifying code at a past commit.

Example of entering detached HEAD:

git checkout a7c9d12

Here, HEAD points to commit a7c9d12, not to a branch like main or dev.

Any new commits you make in a detached HEAD are not tied to a branch, so they can be lost if you switch branches unless you create a new branch for them.

22. What is git checkout used for?

git checkout is used to switch branches or restore files, making it one of the most essential commands in Git.

In modern Git, git checkout has been split into two clearer commands:

• git switch → for switching branches
• git restore → for restoring files

But git checkout still works, and developers commonly use it.

23. What is a feature branch workflow?

A Feature Branch Workflow is a Git development strategy where each new feature, enhancement, or bug fix is developed in its own separate branch instead of directly in the main or develop branch.

The goal is to isolate work so developers can build, test, and review changes without affecting the stable codebase.

24. Difference between git pull and git fetch?

git pull and git fetch both interact with the remote repository, but they behave very differently.

git fetch - Downloads changes but DOES NOT merge

1. git fetch only retrieves new commits from the remote repository and updates your remote-tracking branches (like origin/main). It does not modify your working directory or your current branch.

Example:

git fetch

After fetching, you can compare or review the changes before merging manually:

git merge origin/main

When to use it:

• When you want to see what others have changed without affecting your code
• When you want full control before merging

2. git pull - Fetch + Merge (auto-merge)

git pull does both steps automatically:

• Fetch latest changes
• Merge them into your current branch

Example:

git pull

Your working directory is immediately updated with the remote changes.

When to use it:

• When you want the latest code quickly
• When you trust the remote changes and don’t need review

In short:

• git fetch = safely download changes without touching your work.
• git pull = download + merge changes into your current branch.

Most developers use git fetch when they want control, and git pull when they want quick updates.

25. How do you undo the last commit?

Undoing the last commit depends on whether the commit has been pushed and whether you want to keep the changes or discard them.

Here are the common and safe ways:

1. Undo last commit but KEEP the changes (soft reset)

Use this when you made a wrong commit message or forgot to include a file.

git reset --soft HEAD~1

This removes the commit but keeps all your changes staged.

2. Undo last commit but KEEP changes unstaged (mixed reset - default)

This removes the commit and moves your changes back to the working directory.

git reset HEAD~1

You can edit them again and recommit.

3. Undo last commit and REMOVE the changes (hard reset - destructive)

Use this only if you don’t need the changes.

git reset --hard HEAD~1

This deletes the commit and all file changes.

4. If the commit is already pushed - use revert (safe way)

If you’ve pushed the commit to a shared branch (like main), never reset.

Instead, create a new commit that reverses the old one:

git revert HEAD

This is safe for team collaboration.

In short:

• Use reset to undo local commits (soft/mixed/hard).
• Use revert to undo a commit that is already pushed and shared.

26. Difference between git revert and git reset.

The main difference is that git revert is a safe, forward-moving operation that creates a new commit to undo changes, preserving project history, while git reset rewrites history by moving the branch pointer to a previous commit, potentially losing work.

Example:

git revert <commit-id>
git reset --hard HEAD~1

In short:

• Use git revert to safely undo a pushed commit without breaking history.
• Use git reset to rewrite or clean up local commit history before pushing.

27. What is a soft, mixed, and hard reset?

git reset has three main modes that determine how the staging area and working directory are affected when you move the HEAD pointer to a previous commit.

28. What is an interactive rebase?

Interactive rebase is a powerful Git tool for modifying and cleaning up a series of commits in your project's history. It allows you to control exactly how commits are integrated or changed, rather than just blindly moving them. 

This process involves using the git rebase -i <base-commit> command, which opens a text editor showing a list of commits in the specified range. You can then use various commands to manipulate individual commits. 

Interactive rebase is typically used on local, unshared branches to create a clean, linear, and meaningful history before sharing it with a team.

29. How to squash commits?

Squashing commits means combining multiple commits into a single commit so that your Git history looks clean and meaningful (for example, before merging a feature branch).

The most common way to squash commits is to use an interactive rebase.

Steps to squash the last N commits

Suppose you want to squash the last 3 commits into one:

git rebase -i HEAD~3

This opens an editor showing something like:

pick a1b2c3 First commit
pick d4e5f6 Second commit
pick 789abc Third commit

You then change it to:

pick a1b2c3 First commit
squash d4e5f6 Second commit
squash 789abc Third commit

• pick → keep this commit as is
• squash (or s) → combine this commit into the one above

After saving and closing, Git will ask you to edit the final commit message (you can keep one or write a new combined message).

Important Note: If the branch is already pushed and used by others, squashing rewrites history, so you should coordinate with your team (or avoid squashing shared history).

30. What does git stash do?

git stash temporarily saves your uncommitted changes (both staged and unstaged) and cleans your working directory, allowing you to switch branches or pull updates without losing your work.

It’s like putting your work on a temporary shelf.

You use it when you need to:

• Switch branches quickly
• Pull the latest test code
• Work on an urgent bug fix
• Pause your current work without committing half-done changes

Example scenario:

You're working on feature/login, but suddenly need to fix a production bug on main.

Your changes aren’t complete, so you can't commit them.

• git stash → saves changes and cleans the working directory
• git stash list → shows stashed items
• git stash apply → restores the most recent stash
• git stash drop → removes the stash
• git stash pop → restores + deletes the stash in one step

31. Fork vs Clone vs Branch.

Forking creates an independent copy of a repository on a hosting service (like GitHub) for separate development, Cloning makes a local copy on your machine for offline work, and Branching creates isolated development lines within a single repository (local or remote) for features, all enabling parallel work, but Forks are for public contribution, Clones for local sync, and Branches for features inside a project.

32. What happens during git pull --rebase?

The git pull --rebase command is a combination of git fetch and git rebase. It is used to update a local branch with changes from a remote branch while maintaining a linear commit history.

Here is a breakdown of what happens:

• git fetch: Git first fetches the latest changes from the remote repository and updates the remote-tracking branch (e.g., origin/main). These changes are downloaded but not yet integrated into your local working branch.
• git rebase: After fetching, Git then takes your local commits (those that are not yet pushed to the remote) and temporarily "puts them aside." It then "rewinds" your local branch to the point where it diverged from the remote-tracking branch. Finally, it reapplies your local commits one by one on top of the newly fetched remote changes.

33. You accidentally deleted a branch—how to restore it?

To restore a deleted Git branch, use git reflog to find the commit hash (SHA) of the branch's tip, then git checkout -b <branch-name> <sha> to recreate it locally; for remote/hosted repos (GitHub, Azure DevOps), use the platform's UI to find branch deletions in activity logs or closed pull requests and click "Restore".

Git-GitHub For DevOps

Git & GitHub for DevOps: A Practical Guide to Version Control

Table of Contents

• How Git Came into the Picture
• File System vs Version Control System
• From File System to VCS (Git)
• Understanding Branches in Git
• Local to Remote & Remote to Local in Git
• Using SSH Instead of PAT
• Bonus Tip: Check What’s Changed Using git diff
• Conclusion

How Git Came into the Picture – A Simple DevOps Story:

So one day, the creator of Linux, Linus Torvalds, was writing some code for the Linux project. He made some changes and was happy. But after a few days, he realized — “Oh no! The old version of my code was actually better!” But sadly, he didn’t have the old version saved.

That’s when Linus thought, “I need something to track my code — every change, every version.” So, he created a system called Git, which originally stood for Global Information Tracker (though people joke about this name now). This tool helped him to save every version of his code — like version 1, version 2, and so on — so he could go back anytime and see what changed.

Git became a kind of "code time machine" — a version control system (VCS) that keeps track of code history.

Later, the whole tech world saw this and said, “Wow! Linus made a brilliant tool!” Then many companies started building platforms on top of Git. These platforms helped teams work together more easily. These platforms include:

• GitHub
• GitLab
• Bitbucket
• AWS CodeCommit
• Azure Repos, etc.

But the heart of all of them is still the same — Git.

So in DevOps, Git became a key tool. Why?
Because in DevOps, we want to work faster, safer, and together as a team. And Git helps us do exactly that — it keeps a record of code changes, lets us go back to old versions, and allows teams to collaborate smoothly.

So in short:

Git is a DevOps superhero that keeps track of your code’s full history. It makes working with code — alone or in teams — safe, easy, and smart.

File System vs Version Control System – A Simple DevOps Story

Let’s say you have a folder on your laptop. That’s a normal file system — it stores files locally. You can see when the file was created and who created it. But there’s a problem…

If someone edits the file, you don’t know who did it. If something gets deleted, you can’t bring it back. You also don’t know what the file looked like yesterday or last week.

Now comes the hero — Version Control System (VCS) like Git.

VCS does everything better:

• It keeps the full history of every file.
• It tells you who changed what, and when.
• It stores code locally and can also connect to remote servers.
• If something gets deleted or changed, you can easily go back in time.

From File System to VCS (Git) – Step by Step

Let’s imagine:

You have a folder with some important text files. Right now, it's just a normal folder — in the file system. But you want to put it under Git version control. For that, you need to do a few steps.

Step 1: Folder vs Repository

In the file system, we call it a "folder" or "directory". But in Git (VCS), we call it a repository.

Step 2: Go Inside the Folder

Open your terminal and go inside the folder:

cd 

Step 3: Initialize Git

Now run this command:

git init

This means you're creating an empty Git repository inside your folder.

After that, you’ll see a message:

"Initialized empty Git repository in …/.git"

If you run:

ls -a

You’ll see a hidden folder named .git — that means your folder is now being tracked by Git!

Now, How to Track Files in Git?

Right now, the files in your folder are not yet tracked by Git. You need to pass through some stages:

Git Stages:

1. Untracked (usually shown in red)
2. Staged (ready to be committed — shown in green)
3. Tracked (after commit)

To check your Git status at any time:

git status

To Move a File from Untracked → Staged:

git add 

If You Want to Undo That (Staged → Untracked):

git rm --cached filename

Now, Final Step – Committing the File:

To move from Staged → Tracked, you have to commit it. But Git needs a message to remember what this commit is about. So you do:

git commit -m "Your message here"

Summary:

• File system = basic storage, no version tracking
• Git (VCS) = tracks every change, author, history, and can restore anything
• Folder becomes repository after git init
• Files go through: Untracked → Staged → Tracked
• Use git add, git rm --cached, git commit to move files through stages

Understanding Branches in Git – A Simple DevOps Story

Let’s think of Git like a tree. A tree has a main trunk and several branches. Similarly, Git also starts with a main branch, and from there, we can create other branches to try out new things without touching the main code.

What is a Branch?

In Git, a branch is just a separate line of development.

• The first branch in Git is usually called the master (or sometimes main).
• From this master, you can create more branches like dev, feature-login, etc.
• Each branch is like a copy of the original (at that moment).

Imagine you're writing a story. Instead of editing the main copy directly, you make a photocopy, try new changes on that, and if everything works — you merge it back.

That’s exactly how branches work in Git.

Why Do We Use Branches?

Let’s say your app is live in production and working perfectly. Suddenly, your CEO says, “Please add a new feature!”

Now, you should not change the live (master) code directly. What if your new code has bugs? Production will break!

So instead, you do this:

1. Create a new branch:

   git checkout -b dev

2. Now, you’ll see that all the files from master are also in dev— because it copies the code from the point you branched off.
3. You make your changes safely in dev. You can test, fix bugs, experiment — without touching master.
4. Once everything is working fine, and you're happy with the changes — you merge it back into master.

How to Check Branches?

To see which branches you have:

git branch

The current branch will have a * next to it.

How to Merge a Branch?

Let’s say you are on the master branch and want to bring in the changes from the dev branch. Here's what you do:

1. First, go to the branch where you want the changes to come (e.g. master):

   git checkout master

2. Then, run the merge command:

   git merge dev

Summary – Why Git Branching is So Useful:

• Safe Development: You don’t break the main code while experimenting.
• Teamwork: Different people can work on different branches at the same time.
• Easy Testing: You can test features in a separate branch before going live.
• Organized Workflow: Helps in DevOps pipelines like CI/CD (Continuous Integration/Delivery).

So in short:

Branches = safe space to work → test → merge to master when ready

Local to Remote & Remote to Local in Git – A Simple DevOps Story

Let’s say you’ve been working on a project in your local Git repository — everything’s going great. But now, you want to back it up, share it with others, or work with a team. For that, you need to connect it to a remote Git repository — like one on GitHub, GitLab, or Bitbucket.

As a DevOps engineer, creating a smooth bridge between local and remote is very important.

Step 1: Create a Remote Git Repository

Choose a platform like:

• GitHub
• GitLab
• Bitbucket

Let’s say you choose GitHub.

• Just log in
• Click “New repository”
• Give it a name, and create it.

This new repo is called your remote repository. The folder on your system (with git init) is your local repository.

Step 2: Connect Local to Remote (Using HTTPS + PAT)

There are two ways to connect your local repo to remote:

1. PAT (Personal Access Token) – safer than a password
2. SSH – uses key-based authentication

Let’s first look at PAT.

PAT (Personal Access Token)

GitHub doesn’t allow password-based login for pushing code anymore.

How to Generate a PAT:

1. Go to GitHub → Settings
2. Click on Developer settings
3. Choose Personal Access Tokens (classic)
4. Click Generate new token
5. Name it, give repo access, and generate
6. Copy the token — save it in Notepad (you won’t see it again!)

Step 3: Check if Remote is Connected

Use this to check:

git remote -v

If it shows nothing, your local repo is not yet linked to any remote.</

hr />

Step 4: Add the Remote URL

Go to your GitHub repo page, and copy the HTTPS link.

Now run this:

git remote add origin https://github.com/your-username/your-repo-name.git

Here, origin is just a nickname for your remote URL, which basically holds the URL. It’s a standard practice.

Step 5: Push to Remote (Password Won’t Work)

Run the following command:

git push origin master

It will ask for GitHub credentials — but password won’t work.

GitHub no longer accepts account passwords via Git commands.

Step 6: Use PAT to Set the Remote URL with Authentication

Instead of entering credentials manually, add your PAT directly in the remote URL like this:

git remote set-url origin https://<your-PAT>@github.com/your-username/your-repo-name.git

Now push again:

git push origin master

Success! Your local project is now uploaded to GitHub.

Step 7: Remote to Local – Pull Changes

Let’s say someone else (or you from another system) added a file to the remote repo.

To bring it into your local system:

git pull origin master

This fetches the latest changes from the remote repo into your local one.

Using SSH Instead of PAT (Optional)

The second method to connect is SSH, which is a bit more secure and preferred by many teams.

Step 1: Check or Create SSH Key

If you don’t have an SSH key, run this:

ssh-keygen

This creates two files:

• A private key (stored on your local machine)
• A public key (to be added to GitHub)

Step 2: Add SSH Key to GitHub

1. Go to GitHub → Settings
2. Click on SSH and GPG Keys
3. Click New SSH Key
4. Paste your public key (found in ~/.ssh/id_rsa.pub)
5. Save the key

Step 3: Clone Using SSH

Now, to clone a repo using SSH:

git clone git@github.com:your-username/your-repo.git

No need to enter your username/password — it will use your SSH key instead.

Bonus Tip: Check What’s Changed Using git diff

Let’s say you cloned a repo and made some local changes. To compare what’s different from the original:

git diff

This will show the difference between your current code and the last commit — great for reviewing before pushing.

Summary

Action	Git Command
Check remote link	git remote -v
Add remote repo	git remote add origin <repo-url>
Push code to remote	git push origin master
Pull code from remote	git pull origin master
Set remote URL with PAT	git remote set-url origin <PAT-url>
Generate SSH Key	ssh-keygen
Clone using SSH	git clone git@github.com:username/repo.git
See file changes	git diff

Conclusion

Whether you're just getting started with version control or refining your DevOps toolkit, mastering Git and GitHub is non-negotiable. SSH authentication, clean push/pull operations, and command-line insights like git diff form the backbone of modern infrastructure automation and collaboration. These aren’t just commands—they're career tools.

This guide is part of a larger initiative to empower DevOps engineers with real-world, command-line-first knowledge. Bookmark this article, revisit the commands, and apply them in your daily workflows to truly understand their power.

GitHub Repository

All code snippets and examples from this tutorial are available here:
GitGitHub_DevOps Repository on GitHub

Author

Written by Omkar Goswami — a passionate DevOps and automation engineer who loves simplifying complex workflows through hands-on guides and real-time projects.
Connect on LinkedIn for more technical insights, open-source contributions, and career-building DevOps content.