Learning git was never such fun.Lets simplify the version control journey. Version control is one of those things everyone uses, but not everyone truly understands—especially how it fits into real DevOps workflows.
I spent time working deeply with Git, GitHub, and team-style workflows, and this week honestly changed how I look at source control. Git wasn’t about memorizing commands—it was about understanding why things are done a certain way in real projects.
From “Just Files” to Real Version Control
It all starts by setting up a small project on your local system. At first glance, it was just another folder—but the moment Git was initialized, that folder gained memory.How, use the command as:
`git init`
Every change, every experiment, every rollback suddenly became traceable. That’s when it really hit me:
Git isn’t about commands—it’s about accountability and confidence.
We use the command git status for tracing the changes. We create a new file for example index.html but how will git know its for the versioning or project so we add it by git add index.html command.
Now git knows the file is for git but what about the pals who work with you on the same project so we are making a commit for a understanding with the command git commit -m "Here goes the message"
I also worked with both local and global Git identities, which made me realize how important author attribution is in professional environments, especially when multiple teams and repositories are involved.Here we add our name and email while creating a config so that we all know who has done the commit, you now now where the accountability comes from!
The commands used for setting up are :
Suddenly we want to add a new file to the project so we create it but this time in a different way.Git is like a tree, the master/main is the tree trunk and we have to create a new branch and then merge it as different people are involved and we need to ensure that the main project is not effected.Imagine like its a production environment so slight change in the code can bring the application down.
So we create a new branch that a new file with the command as (lets say its a feature update/contact-page)
`git checkout -b feature/contact-page`
We then have to make the required changes and merge it.We can use the commands as
git checkout master
git merge feature/contact-page
So now we have create a new branch, edited the required and we have merged it with our main.(that is the tree trunk)This is the simplest way to understand git.
But what about enormous code on the internet.Aren't those like roots all over the earth. Imagine you wish to fetch something like some other persons or other organizations repository(used repo in short)so what we do, we use a fork to use the code for own github account.
Github is used as an example here so the enormous pool of code is the github, I can fork any public repo by forking it by simple pressing the button of 'fork'.
Now what, we have cloned it to our own repo.Lets imagine that you are a developer in an xyz organization with a repo where you are required to fork, clone and then update the code.Lets say you are two friends working on two different pages(branches) and would report to a project lead.So you for the particular code would work and make changes as per requirement and then create a pull request.By creating a pull request you are asking your manager to review the code.
But here's where security comes in, we have to set up a secured connection from your local machine to the organizations account.
So we generate PAT, nothing but access tokens that allow you to pass through the authentication grids.
Later we check the connectivity by
ssh -T [email protected]
These are the commands to set a origin URL and upstream URL:
git remote set-url origin
git remote add upstream
You can verify the origin and upstream by the command as :
git remote -v
Once you have all set for the merging of your code and for your review you can then you can push it by
`git push -u origin nameofthebranch`
You can then create a pull request by going to your fork on GitHub, Click Compare & pull request.Ensure PR target is correct and create a Pull request.This is the general flow or understanding.
P.S. This post is a part of DevOps Micro Internship (DMIByPravinMishra) by
If you’d like to join cohort 3.
Join the Discord community here: https://discord.com/invite/GKUuEaknTG