Mastering GIT: Version Control & SCM Essentials

Day 11 of DevOps I thought I knew Git. Turns out I only knew GitHub. Git is a distributed version control system : it tracks every change you make to your code, locally on your machine. GitHub is just where you store it online. They are not the same thing. Today I actually used Git commands for the first time. Here's how it went: git init : initialized my first local repository git add : staged my changes git commit -m : saved my first snapshot But first commit failed. Git threw an identity error : it didn't know who I was. Turns out Git requires you to set your identity before committing anything. git config --global : fixed it permanently Then things got interesting: git diff : showed me exactly what changed between versions git log : showed my entire commit history with IDs git reset --hard : rolled back to a previous version instantly That last one hit different. One command and your code goes back in time. Git doesn't just save your work. It saves every version of it. Moral of the day: GitHub is the house. Git is the foundation it's built on. #DevOps #Git #LearningInPublic

Three phase of git in local machine. 1. Untracked 2. Staged 3. Committed Let discuss about them below: Untracked: Every file in a directory after git init is below in this. Basically file are exits but the they are not a part of git version control. That means if any files are deleted from here we can restore them via git. If we want check git status via the command: git status; this files are under the untracked files and the file names are red colored. Staged: Basically a file in being a part of version control from here. If any file which is add in this phase will show the file name in green color and under the changes to be committed category. We can restore any file from here if they deleted from our local machine. Committed: This phase is the final phase of a local git repository. Here we can create a version of our work with a meaning full message. If we commit anything we can see them via git log command. Git status command won't give us any result it will say nothing to commit. [N. B: If any file(s) or directory is included at .gitignore can't tracked by git. It will automatically vanish for git] #devOps #git #learnNewThings

🚀 DevOps Journey – Day 17 / 100 Today I learned a real-world Git scenario that every developer faces 🔥 ⸻ 🔹 🔐 Git with SSH (Secure Way) • Generate SSH key → ssh-keygen • Add public key to GitHub SSH settings • Use SSH URL instead of HTTPS 👉 git remote add origin <SSH_URL> 👉 git push origin branchname 💡 No more entering username/password every time! ⸻ 🔹 ⚙️ Basic Config (Recap) • git config --global user.name "yourname" • git config --global user.email "youremail" ⸻ 🔹 📏 Sigma Rule of Git (Golden Rule) 👉 Always PULL before PUSH ⚠️ ⸻ 🔹 🔥 Real-Time Scenario (Important) 1️⃣ Change a file directly in GitHub 2️⃣ Commit changes in GitHub 3️⃣ Now from Local: • Modify same file • Try git push ❌ → ERROR 👉 Why? Because local repo is outdated ⸻ 🔹 🛠️ Solution ✔️ First try: git pull ❌ Still conflict? 👉 Fix using: • git reset --soft HEAD~1 • git stash • git pull • git stash apply • Resolve conflicts • git push ✅ ⸻ 🔹 🔀 GitHub Merge • Use Compare & Pull Request • Review changes • Merge safely into main branch ⸻ 💡 Pro Tip: Most Git errors happen due to not pulling latest changes Follow the rule → Pull → Modify → Push Consistency makes you industry-ready 💪 #DevOps #Git #GitHub #Linux #VersionControl #100DaysOfDevOps #LearningJourney #Cloud #Automation #RealTimeScenario #frontlinesedutech #flm #frontlinesmedia #MultiCloudDevops

Once Git starts making sense, your workflow becomes much smoother. If GitHub still feels a bit messy sometimes, this breakdown helps: - Repository = your project folder - Commit = save point of your work - Branch = separate version to work safely - Merge = combine changes - Push / Pull = sync your code Most useful Git commands (with purpose): git init → start a repo git clone <url> → copy project locally git status → check changes git add . → stage files git commit -m "msg" → save changes git push → upload changes git pull → get latest updates git branch → list branches git checkout -b dev → create & switch branch git merge dev → merge changes Simple strategies that actually help: • Don’t rush commands → understand what you’re doing • Use branches instead of working directly on main • Write clear commit messages (helps in debugging later) • Check git status before every commit • Pull before you push (avoids conflicts) If this helped you, repost it — it might help someone simplify Git. Save this sheet so you can revisit it while practicing. Comment "GitHub" and I’ll send the full PDF. Done forget to connect Sahil Hans for more!🤝

Most people don’t struggle with Git. They struggle with the workflow. You learn commands like: git add git commit git push But still feel confused. Because Git is not about commands. It’s about understanding the flow. Modify → Stage → Commit → Push Once this clicks… everything becomes simple. 🔥This PDF explains Git the way it should be learned: • What Git actually does (version control) • Difference between Git and GitHub • How changes are tracked step-by-step Then builds the real workflow: • Initial setup (config, init) • Staging vs committing • Viewing history (log, status) • Working with branches • Merging changes And the part most people struggle with: • Connecting local repo to GitHub • Push, pull, clone • Working with remote repositories Plus something very important: Undoing mistakes. • Revert • Reset • Amend Because that’s what you’ll actually need in real work. These are not just commands. It’s clarity. A simple way to use this: 1. Don’t memorize commands 2. Understand the flow 3. Practice on a small project 4. Break things → fix them That’s how Git actually clicks. Save this — you’ll revisit it again and again. Follow Sahil Hans for more! 🤝

🚨 Stop delivering IT work outside of Git. In 2026, there’s no valid reason for code, scripts, or IaC to live in emails, ZIP files, or shared folders. If it’s not in GitLab (or any Git-based platform), it simply doesn’t exist. 👉 No versioning 👉 No traceability 👉 No rollback 👉 No accountability And that’s how you lose control of your IT. Today, a Git repository is not just “where code lives”: It’s your 📦 delivery point It’s your 📚 documentation It’s your 🔍 audit trail It’s your 🚀 deployment trigger Especially with IaC (Terraform, Ansible…), Git becomes the single source of truth for your infrastructure. No Git = ❌ fragile systems ❌ knowledge silos ❌ unreproducible environments ❌ risky deployments On the other hand: With Git + GitLab 👇 ✅ every change is tracked ✅ every decision is documented ✅ every version is recoverable ✅ every deployment is controlled This isn’t a “best practice” anymore. 👉 It’s a baseline requirement. 💬 Curious: do you still see deliverables outside Git in your projects? #gitlab #git #CICD

I thought Git was just “save your code.” I was completely wrong. Recently, I started revising Git again… And I realized how many basics I had ignored earlier. At first, I used Git like a backup tool. Just add → commit → push and done. No branches. No proper workflow. No real understanding. Then one day… I faced my first merge conflict. Everything broke. Files messed up. Code overwritten. Total confusion. And during this revision phase, it hit me: 👉 I didn’t have a Git problem. 👉 I had a fundamentals problem. So this time, I went step by step. Here’s what I truly understood • Core commands matter more than you think status, add, commit, diff, reset, restore → These are not basic… they are everything. • Branching is a superpower Work on features without touching main code. • Checkout Switch versions like time travel. • Merge Combine work properly… or be ready for chaos. • Merge conflicts Not scary when you actually understand them. • Push & Pull workflows Coding is not solo. It’s collaboration. • Git log Every commit tells a story. Big realization during revision: Most of us don’t lack tools… We lack clarity. And revision is where real learning happens. Now I don’t just use Git. I understand what it’s doing. That changes everything. Are you also revisiting fundamentals? Or still stuck jumping from one tool to another? Let’s discuss 👇 #Git #Developers #LearningJourney #Coding #SoftwareEngineering

My Small but Powerful Workflow Upgrade This month marks 20 years of Git — the version control system that quietly powers nearly every developer’s daily work. Huge thanks to Linus Torvalds for creating it back in 2005. What began as a practical fix for the Linux kernel has become an essential part of modern software development. 🙌 This milestone got me reflecting on my own Git journey. I used to live entirely in the terminal for version control. Then a senior developer at my organization introduced me to VS Code’s built-in Source Control panel (the Git icon on the sidebar). And it added exactly the layer of safety I didn’t know I was missing — especially when pushing changes. Now my daily flow is more intentional and mindful: ✅ Open the Source Control view ✅ Instantly see every changed line with clear visual highlighting (added/removed) ✅ Review the code one more time in the beautiful side-by-side diff ✅ Stage only the exact hunks or selected lines I want — not the whole file ✅ Write a clean commit message and push This visual review step gives me that extra security and safety — like a quick second pair of eyes catching anything I might have missed in the rush. I’m not saying the GUI is always better than the CLI. Far from it. For complex tasks like interactive rebasing, advanced scripting, cherry-picking, or heavy history rewriting, the CLI is still far more powerful and flexible — and many experienced developers rightly prefer it for those scenarios. But for the everyday cycle of reviewing changes → selective staging → thoughtful commits → pushing, VS Code Source Control has become my preferred safety net. It keeps me more careful without slowing me down. Grateful to my senior for teaching me this habit — and to Linus for giving the world Git in the first place. Small shifts like this really do improve code quality and peace of mind. What about you? Do you mix VS Code Source Control for daily visual reviews with CLI for power-user tasks? Or do you have a favorite tip (hunk staging, GitLens, inline diffs)? Drop your workflow or thoughts in the comments 👇 — especially on this 20-year milestone! #Git #VSCode #SourceControl #DeveloperTips #VersionControl #Git20Years #DevLife #LearningJourney

🚀 Day 02/100 – Git Configuration, Amend & .gitignore Today I focused on key Git operations related to commit management and repository handling. 🔹 What I revised today: • Git configuration to set username and email for commits • Using git commit --amend to modify the latest commit (message, author, or changes) • Understanding the purpose of .gitignore to avoid tracking unwanted files 🔹 Hands-on I practiced: • git config user.name / user.email • git commit --amend -m "message" • git commit --amend --no-edit • Creating and using .gitignore file 💡 Key Takeaway: Proper configuration and controlling what gets committed helps in maintaining clean and meaningful version history. ⚡ Insight: Using .gitignore effectively prevents unnecessary files from being tracked and keeps the repository organized. Day 2 ✅ #DevOps #Git #100DaysOfDevOps #LearningInPublic

<written by a human being> If you haven't worked with Git repositories before, now's the perfect time to start. All you need to do is go to GitHub or GitLab - depending on your personal preference (they're essentially the same thing) - and create a new repository. The repository can be public or private, again, depending on your project. I usually create private repositories so I don't expose them unnecessarily before the time is right. The repository itself should be empty: don't create anything inside it, including what the Git service suggests by default. Once the repository is created, you need to sync it with your working directory on your local machine. You can do this yourself via the command line. Or you can ask an AI agent to handle it - just send it the repository URL and ask it to sync with the folder it was launched from. This is the key point: we need to be working in coding mode. Meaning this is Claude Code or Codex running from the command line, or - if you're working from an app - in Code mode. And the coding agent must be running from inside the project folder, where all the project files are located and where the repository will live. The prompt looks something like this: "Sync the current folder with the repository [repository link]" - and here you paste the link to your repository.