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

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

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.