Git Installation & Setup for DevOps Engineers

Day 1&2: Why I finally stopped avoiding the Terminal !!! I’ve known for a while that if I want to make it as a DevOps/SRE Engineer, Git isn't just an "extra skill"—it’s the foundation. Today, I officially dove into the world of Version Control. Why now? I used to think GitHub was just a place to host code. But for SRE roles, "Infrastructure as Code" starts with... well, code. If you can’t manage versions of your scripts or configs, you can't manage a reliable system. The "Cool" Factor: I found out some pretty wild history today. Did you know Linus Torvalds (the guy who created Linux) built Git in just a few weeks? He was frustrated with the tools available at the time and basically built Git to be a "stupid content tracker." It’s ironic that something built out of frustration now powers almost every major tech company on earth. From CVCS to DVCS: I also dug into how we got here. I learned that we moved from Centralized VCS (CVCS)—like SVN or Perforce, where you’re dependent on a single server—to Distributed VCS (DVCS) like Git. Now, every contributor has a full copy of the history locally. It’s faster, more secure, and allows for much better collaboration. Getting under the hood: Instead of just reading theory, I wanted to see the "Distributed" part in action. I set up a VMware instance, created two separate users with their own directories, and initialized local repos using git init. My big takeaways: - Git isn't just a "cloud backup", it's a local engine that tracks history before a single byte even hits the internet. - In SRE, we treat infrastructure like code. If I can’t manage a local repo across different users on a VM, I can’t manage a fleet of servers later. - It’s all about data integrity, knowing exactly who changed what via those SHA-1 hashes. Day 1 (and 2) in the books. The terminal is finally starting to feel like home. #DevOps #SRE #Linux #Git #LearningInPublic #BuildInPublic #Github

🚀 Day 23 of #90DaysOfDevOps — Git Branching & GitHub Workflow Today I worked on one of the most important concepts in Git — Branching 🌿 This is where Git actually becomes powerful in real-world DevOps and development workflows. 🔧 What I practiced today: ✔ Creating and switching branches (git branch, git switch, git checkout) ✔ Making isolated commits on feature branches ✔ Verifying that changes don’t affect the main branch ✔ Deleting unused branches ✔ Pushing multiple branches to GitHub ✔ Understanding origin vs upstream ✔ Learning git fetch vs git pull ✔ Practicing clone vs fork workflow 💡 Key Learning: Branching allows teams to work on features, fixes, and experiments independently without breaking production code — this is the foundation of CI/CD pipelines. 🧪 Hands-on Work: Created feature branches (feature-1, feature-2) Made commits on different branches Tested branch isolation Synced changes between local and remote Practiced full GitHub workflow (push, pull, fork, clone) 📂 GitHub Repository: 👉 https://lnkd.in/g9i-KJx3 Consistency is the real game changer. Learning in public 🚀 #DevOps #Git #GitHub #Linux #Automation #LearningInPublic #90DaysOfDevOps #DevOpsEngineer #TrainWithShubham

Day 12/100 – Git & GitHub Deep Dive: Restore, Reset & Force Push 🔁🐙 Today was all about fixing mistakes in Git the right way — something every developer & DevOps engineer faces in real projects. I learned how to safely undo changes, uncommit code, and even force push when local and remote histories don’t match. 🛠️ What I did today ✔ Cloned a GitHub repository ✔ Modified files in the working directory ✔ Checked file states using git status ✔ Used git restore to discard changes ✔ Used git restore --staged to unstage files ✔ Configured Git username & email ✔ Committed changes with proper messages ✔ Explored git reset (soft, mixed & hard) ✔ Understood commit history using git log ✔ Fixed wrong commits using reset ✔ Used force push to sync local & remote branch ✔ Learned how companies handle private repos & tokens 🔁 Git File Lifecycle Working Directory → Staging Area → Commit History → Remote Repository (GitHub) 🔄 Reset Types Explained Soft Reset → Removes commit → Keeps changes staged Mixed Reset → Removes commit → Keeps changes in working directory Hard Reset → Removes commit → Deletes changes completely (⚠️ careful) 🚀 Important Commands Used gitclone <repo-url> git status # Discard local changes git restore index.html # Unstage files git restore --staged index.html # Stage & commit git add . git commit -m"Updated index.html" # View history gitlog --oneline # Reset commits git reset --soft HEAD~1 git reset --mixed HEAD~1 git reset --hard HEAD~1 # Force push git push -f origin main 🔐 Private Repository Access ✔ Companies use private repositories ✔ Cloning requires Personal Access Token (PAT) ✔ Tokens are safer than passwords ✔ Token-based access is industry standard 💡 Key Learnings ✔ Git mistakes are normal — fixing them is a skill ✔ Restore helps discard unwanted changes ✔ Reset helps fix wrong commits ✔ Force push should be used carefully ✔ Understanding Git internals = confidence at work ✔ Essential knowledge for DevOps & real projects 📌 Save this post — Git reset & force push are frequently asked in interviews. #Git #GitHub #DevOps #VersionControl #SoftwareDevelopment #CloudCareers #Linux #100DaysOfDevOps #SRTechOps

SUBJECT: Git looks simple… until the first real project 😅 Most developers learn Git by memorising 3 commands: git add git commit git push And it works… until one day: ⚠ merge conflict appears ⚠ branch history breaks ⚠ commit disappears ⚠ panic starts That’s when we realise Git is not about commands — it’s about understanding version control. While improving my DevOps skills, I found a very helpful Git resource that explains things properly from beginner → professional level. It covers: ✅ How to create repositories correctly ✅ Working with branches and remotes ✅ Rebasing vs merging (when to use what) ✅ Recovering lost commits safely ✅ Real Git workflows used by teams Honestly, Git becomes much easier once the concepts are clear. Curious 👇 Which Git topic confused you the MOST when learning? 1️⃣ Merge conflicts 2️⃣ Rebasing 3️⃣ Branching strategy 4️⃣ Lost commits recovery Reply with the number 🙂 Save this post if Git ever scared you once 😄 #git #devops #github #linux #cloud #developer

𝗜 𝘂𝘀𝗲𝗱 𝘁𝗼 𝗯𝗲 𝘀𝗰𝗮𝗿𝗲𝗱 𝗼𝗳 𝗚𝗶𝘁… 𝗵𝗲𝗿𝗲’𝘀 𝗵𝗼𝘄 𝗜 𝗳𝗶𝗻𝗮𝗹𝗹𝘆 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗼𝗼𝗱 𝗽𝘂𝘀𝗵 & 𝗽𝘂𝗹𝗹.🤖 . When I started using Git, everything felt confusing. The commands… the errors… the merge conflicts. And the worst part? I didn’t understand what was happening behind the scenes. Until one day, a senior explained it to me in the simplest way ever. And it finally clicked. So here’s the same explanation : 🔼 PUSH → “Take my local code and upload it to GitHub.” Whatever changes I made on my laptop → send them to the remote repository. Simple. ⬇️ PULL → “Bring the latest code from GitHub to my laptop.” Maybe someone else updated the project… Maybe I made changes from another device… Pull always keeps your local folder up-to-date. 💡 The simplest way to remember: PUSH = Upload PULL = Download That’s it. Once I understood this, Git suddenly stopped feeling scary. ✨ Bonus Tip: Always pull before you push. It avoids 80% of the beginner errors. We overthink Git, but it’s just communication: Your laptop ⇆ GitHub Your changes ⇆ The main code What was the most confusing Git concept for you when you started? 𝐜𝐨𝐦𝐦𝐞𝐧𝐭𝐬 𝐝𝐨𝐰𝐧👇 #Git #GitHub #DSA #LearningInPublic #DeveloperTools #VersionControl #CodeNewbie #ProgrammingTips #tech

Once I understood the core Git commands, everything started making sense. So here’s a simple GitHub crash course for anyone who’s still figuring it out… Struggling with how to use GitHub properly? This quick breakdown helped me a lot — and it’ll help you too: Basic concepts: Repository → Your project folder (can be local or online) Commit → A saved snapshot of your changes Branch → A parallel version of your project to work safely Merge → Combining changes from different branches Clone / Push / Pull → Ways to sync local and remote repositories Essential Git commands (with purpose): git init → Initialize a new Git repository git clone <url> → Copy a repository to your system git status → Check current changes git add . → Stage all files git commit -m "message" → Save changes with a message git push → Upload changes to GitHub git pull → Get the latest updates from GitHub git branch → View all branches git checkout -b dev → Create and switch to a new branch git merge dev → Merge the dev branch into main Repost it to share in your network  Save it if you don't wanna miss it

A Day of my DevOps Journey: Mastering Git Beyond the Basics! 🚀 Git is more than just push and pull. Today, I dove into managing history and fixing mistakes. Here’s a quick breakdown of what I learned: 🔹 Configuration Set your identity so your team knows who made the changes. git config user.name "Your Name" git config user.email "Your Email" 🔹 Undoing Changes (Reset) --soft HEAD~1: Deletes the commit but keeps your work in the staging area. --hard HEAD~1: Deletes the commit AND your work. Use with caution! 🔹 Fixing Commits (Amend) Forgot a file or made a typo in the message? git commit --amend: Update the last commit without creating a new one. 🔹Selective Merging (Cherry-Pick) git cherry-pick <commit-id>: Grab a specific commit from another branch and apply it to your current one. 💡 Pro-Tip: If you ever get lost, git reflog is your best friend—it shows a history of everything you've done in the local repo !! #DevOps #Git #VersionControl #Linux #TechLearning #CloudComputing

Day 30 of #100DaysOfDevOps 🚀 Today’s task focused on cleaning up a Git repository by resetting its commit history to a stable point. The repository had a few extra test commits that were no longer needed, and the goal was to move the branch back so that only two commits remained: the initial commit and the add data.txt file commit. What I worked on I navigated to the repository on the storage server and reviewed the commit history to identify the correct commit to roll back to. Once I confirmed the target commit, I reset the branch so that HEAD pointed back to add data.txt file, effectively removing the unnecessary test commits from the history. After verifying that only the required commits remained, I pushed the updated branch to the remote repository. Key takeaway Not every situation calls for a revert but sometimes a clean reset is the right approach, especially when working with test repositories or preparing for a clean release state. Understanding the difference between rewriting history and preserving it is a critical Git skill for DevOps engineers. This task reinforced: How Git branch pointers and HEAD work When to use reset vs revert How to responsibly update shared repositories The importance of maintaining a clean and reliable commit history Thirty days in, and the Git concepts are getting deeper and more practical. #DevOps #Git #VersionControl #Linux #CI_CD #100DaysOfDevOps

🚀 I just published a new article about Git & GitHub Basics! In this article, I explained: ✅ What is Git ✅ Why we use Version Control ✅ What is GitHub ✅ Branching and collaboration ✅ Pull Requests and team workflow This guide is helpful for beginners who want to understand how developers manage and collaborate on code in real projects. 📖 Read here: https://lnkd.in/gtvdZYRm #Git #GitHub #VersionControl #Learning #DevOps #SoftwareDevelopment

Git Expertise – 2–3 Years of Hands-On Experience With 2–3 years of practical experience working with Git, I’ve developed strong version control practices that support collaborative and scalable development workflows. 🔹 Core Git Skills: ✔️ Repository initialization & cloning ✔️ Branching strategies (feature, release, hotfix) ✔️ Merging & resolving merge conflicts ✔️ Rebasing for clean commit history ✔️ Cherry-pick & revert operations ✔️ Stashing changes during context switching ✔️ Tagging releases & version management ✔️ Writing meaningful commit messages 🔹 Advanced Concepts: 🔸 Implemented Git workflows like Git Flow 🔸 Managed pull requests & code reviews on platforms like GitHub and GitLab 🔸 Integrated Git with CI/CD pipelines in Jenkins 🔸 Managed access control & branch protection rules 🔸 Handled submodules & repository restructuring 🔹 Real-Time Experience: ✅ Collaborated with cross-functional teams using distributed version control ✅ Maintained structured branching strategies for production stability ✅ Resolved complex merge conflicts in large repositories ✅ Automated build triggers based on Git commits