Git's 20-Year Reign as Version Control Standard

🚀 𝟗𝟎 𝐃𝐚𝐲𝐬 𝐨𝐟 𝐃𝐞𝐯𝐎𝐩𝐬 | 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐢𝐧 𝐏𝐮𝐛𝐥𝐢𝐜 | 𝐇𝐚𝐧𝐝𝐬-𝐎𝐧 | 𝐏𝐫𝐨𝐣𝐞𝐜𝐭𝐬 🌳 Branching out into Version Control: My First Git Repo! Day 22 of #90DaysOfDevOps is done! ✅ Today, I transitioned from scripting to mastering Git—the absolute backbone of DevOps and modern software engineering. 👨💻 I set up my global config, initialized my first repository, and got hands-on with the core workflow: Working Directory ➡️ git add (Staging) ➡️ git commit (Repository). ✅ git init → git add → git commit → Repeat! 💡 Biggest Aha! Moment: Understanding the Staging Area. It isn’t just an extra annoying step; it’s a drafting space that lets you group related changes together before sealing them into a commit, keeping the project history clean and logical! 🔗💻 GitHub Repo: https://lnkd.in/dZsmFiQT #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Git #GitHub #VersionControl #DevOpsJourney

🔁 Git Reset vs Git Revert — I Used to Think They Were the Same… Early on, I assumed both commands did one simple thing: “Undo changes” But while working on a project, I realized they solve completely different problems. And using the wrong one can break your workflow. 🔙 git reset (Rewrites History) - Moves the branch pointer backward - Can remove commits from history - Affects your local repository Use when: - Undoing local commits - Cleaning up commits before pushing Common Commands: - git reset --soft HEAD1 → Undo commit, keep changes staged - git reset --mixed HEAD1 → Undo commit, keep changes unstaged - git reset --hard HEAD~1 → Remove commit + delete changes Example: Fixing unclear commits before pushing ↩ git revert (Safe Undo) - Creates a new commit that reverses changes - Keeps history intact - Safe for shared repositories Use when: - Changes are already pushed - Working in a team environment Common Commands: - git revert HEAD → Revert last commit - git revert <commit-id> → Revert specific commit Example: Reverting a faulty production change 🎯 Takeaway: Never use reset on shared branches. Prefer revert when collaborating. #Git #GitHub #DevOps #VersionControl

🚀 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

Explain a scenario where you used git fork instead of git clone. Why was forking necessary 🤔 ... ✅ I used git fork when I contributed to a DevOps project in my org on GitHub. Since I didn’t have write access to the original repository, I forked it into my GitHub account, made changes, and then created a pull request from my fork to the upstream repo. 📘 Detailed Explanation In this scenario, the original repository belonged to an organization. I wanted to fix a bug in their Helm chart setup for Kubernetes deployments. Because I didn’t have contributor rights to push directly, I used the Fork button on GitHub to create a personal copy of the repository under my own GitHub username. From there: I cloned my fork to my local system:git clone https://lnkd.in/gWYH6Y6e Created a new branch, made the fix, committed the changes. Pushed the branch to my fork:git push origin bugfix-helm-values Finally, I submitted a pull request to the original repository. Using git clone directly on the upstream repo wouldn't have helped because I couldn’t push changes or open a PR without a fork. So, forking gave me independence and write access on my own terms, while still contributing back to the main project.

Git Series | Day 1: Architecture of Collaboration — From VCS to Distributed Git 🌐 Today, I officially moved beyond local administration into the "Source of Truth" for all modern software development. I shifted from just saving files to understanding the Distributed Version Control System (DVCS) architecture that powers the global tech industry. 1. The Problem: Centralized VCS (The "Old Way") In a traditional VCS, developers are tethered to a single central server. If that server goes down, the entire team’s productivity stops. It represents a "Single Point of Failure" that modern, high-availability DevOps cannot afford. 2. The Solution: Distributed Git (The "New Way") Git revolutionized this by giving every developer a full copy of the repository on their Local System. • Reliability: If the main server fails, any local repository can be used to restore it completely. • Speed: Since the entire history is on my machine, operations like commits and logs happen at lightning speed without needing an internet connection. • Independence: I can work on "Updated Feedback" locally and sync with the remote server (GitHub/GitLab) only when the code is verified and ready. 3. The Developer's "Three Trees" I mastered the internal flow of how Git tracks work: • Working Directory: The actual folder where I am modifying my shell scripts. • Staging Area (Index): The "Waiting Room" where I selectively prepare changes before they are finalized. • Local Repo: The database where my code is officially snapshotted and timestamped as a Commit. #Git #VersionControl #DevOps #SystemArchitecture #100DaysOfCode #SoftwareEngineering #LinuxAdmin #GitHub

Git isn't just a version control tool — it's the starting point of your entire delivery pipeline. Every CI/CD pipeline, every deployment, every infrastructure change begins with a Git event. A push, a merge, a pull request. Here are the Git commands that actually matter in DevOps: The daily basics: → git clone — copy a repo to your local machine → git pull — get the latest changes from remote → git add . — stage all changes → git commit -m " " — save your changes with a message → git push — send your changes to remote Branching: → git branch — list all local branches → git checkout -b name — create and switch to a new branch → git merge branch-name — merge changes from one branch into another Debugging and recovery: → git log --oneline — see commit history in a clean format → git diff — see exactly what changed between states. → git revert <commit> — undo a commit safely without rewriting history → git stash — temporarily save changes you're not ready to commit Status: → git status — Run git status constantly. It tells you exactly where you are, what's staged, what's not, and what branch you're on. It saves so much confusion. Understanding Git properly means understanding how the entire delivery process begins. What Git command do you wish you had learned earlier? 👇 #DevOps #Git #VersionControl #CICD #LearningDevOps #BeginnerDevOps #TechCareers #LearningInPublic

Git Series | Day 9: Optimization & Deployment — Squash, Cherry-Pick, and .gitignore 🚀 As I near the end of this series, I am focusing on the "polishing" tools that professional DevOps Engineers use to ensure their repositories are clean, secure, and ready for production. 1. Squash: Consolidating the Journey Why show 10 "work-in-progress" commits when one clean commit will do? Squash allows me to combine multiple commits into a single, meaningful entry. The Command: git rebase -i HEAD~number The Workflow: In the interactive editor, I keep the first commit as "pick" and change the others to "squash." The Benefit: It keeps the master branch history concise and high-level for senior reviewers. 2. Cherry-Pick: Surgical Precision Sometimes you don't want an entire branch; you just want one specific fix or feature. The Concept: Picking a single commit from one branch and applying it to another. The Command: git cherry-pick <commit-id> The Use Case: Great for pulling a critical hotfix from a development branch directly into production without bringing unfinished features along. 3. .gitignore: The Silent Guardian A professional repository should never contain logs, environment variables, or temporary build files. The Mechanism: By creating a .gitignore file, I tell Git which files to permanently ignore from tracking. Standard Exclusions: I typically exclude *.log, .env (security), and folders like /db or node_modules. The Result: Smaller repository size and zero risk of pushing sensitive credentials to GitHub. 4. Deployment: Hosting via GitHub Pages Git isn't just for tracking; it’s for delivering. I practiced hosting static web applications directly from a repository. Push your code to a new GitHub repository. Navigate to Settings > Pages. Select the master branch and save. Your application is live and accessible via a public URL! My use of .gitignore ensures that sensitive configuration data and "garbage" files never enter the version control system. I Streamline Code Reviews: By squashing messy development commits before merging. #Git #DevOps #100DaysOfCode #WebDeployment #GithubPages #CleanCode #SoftwareEngineering #SysAdmin #GitIgnore

🚀 Day 5/7 – Git & GitHub Journey | Debugging & Restore Power Today was all about fixing mistakes in Git like a pro 🔥 Because real developers don’t just write code… they debug & recover smartly. 💡 Focus: Git Debugging & Restore Commands Mistakes are common: ❌ Wrong file changes ❌ Accidental commits ❌ Deleted important files 👉 Today I learned how to fix ALL of these using Git itself. ⚙️ Practical Tasks I Performed: ✅ 1. Checked file changes Used git status and git diff Understood staged vs unstaged changes ✅ 2. Restored modified files git restore filename 👉 Reverted file back to last committed state ✅ 3. Unstaged files git restore --staged filename 👉 Removed file from staging area ✅ 4. Undo last commit (without losing code) git reset --soft HEAD~1 ✅ 5. Completely discard changes git checkout -- filename (older way) 🧠 Key Learning: Git is not just version control… It’s a complete recovery system if you know the right commands 💪 🔥 Real DevOps Insight: In real projects, mistakes happen frequently. Knowing how to debug and restore safely saves time, code, and production issues. 📂 Skills Gained: Git Debugging 🔍 Code Recovery ♻️ Safe Commit Handling Better Development Workflow #Day5 #Git #GitHub #DevOps #Debugging #LearningInPublic #Automation #AWS #Cloud #DevOpsJourney

𝗚𝗶𝘁 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗜 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗼𝗼𝗱 𝗼𝗻𝗹𝘆 𝗿𝗲𝗰𝗲𝗻𝘁𝗹𝘆 When I started using Git, I honestly thought branching simply means "create branch, push code, done." That's it. Job over. But while working on actual projects, one thing hit me hard. The wrong branching strategy does not just cause small hiccups. It creates confusion that keeps piling up and becomes very difficult to manage later. So let me share what I understood, in simple words. 𝗠𝗮𝗶𝗻 𝗼𝗿 𝗧𝗿𝘂𝗻𝗸-𝗕𝗮𝘀𝗲𝗱 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁: Everyone commits directly to one main branch with small, frequent updates. Simple to follow, but it needs a lot of discipline from every single person on the team. 𝗙𝗲𝗮𝘁𝘂𝗿𝗲 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴: Every feature gets its own separate branch. Once the work is done, it gets merged back to main. Very easy to manage and track, and honestly the most commonly used approach in most teams I have seen. 𝗚𝗶𝘁 𝗙𝗹𝗼𝘄: This one has dedicated branches for everything, main, develop, feature, release, hotfix. Slightly more process-heavy but very useful once your project or team starts growing. 𝗥𝗲𝗹𝗲𝗮𝘀𝗲 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴: A separate branch is created for each release and all bug fixes are handled there before anything goes live. Very helpful when you want stable and controlled deployments. One thing I genuinely realised after all this is that there is no perfect branching strategy that works for everyone. It completely depends on your team size, your project, and how frequently you are shipping things. Personally, feature branching felt like the most natural starting point for me and I still use it quite often. #DevOps #Git #GitHub #CICD #VersionControl #CloudComputing #Docker #Kubernetes #AWS #Automation #LearningDevOps #DevOpsTips

🚀 DevOps Journey – Day 18 / 100 Today I learned real-time Git workflow with multiple developers + GitHub repo management 🔥 ⸻ 🔹 🧑💻 Real-Time Scenario 👨💻 Dev1 → Already developed code & pushed to GitHub 👨💻 Dev2 → New joiner (no code in local system) 👉 What should Dev2 do? ✔️ Clone the Repository • git clone <repo_url> → Entire code + history comes to local ⸻ 🔹 🔄 Clone vs Pull ✅ Clone • First time download • Full repo + all branches ✅ Pull • Get latest changes • Used after clone 💡 Pull = Fetch + Merge ⸻ 🔹 🌿 Branch & Sync • git branch -a → Show local + remote branches 👉 Workflow: 1. Make changes locally 2. git push → Send to GitHub 3. Other dev makes changes 4. git pull → Get updates ⸻ 🔹 🔍 Fetch vs Merge • git fetch origin branch → Check new commits (no merge) • git merge origin/branch → Merge changes into local ⸻ 🔹 ⚙️ GitHub Repository Settings 📌 You can manage repo using UI: • Rename repository • Change default branch • Change visibility (Public → Private) • Transfer ownership • Archive (read-only mode) • Delete repository (Danger Zone ⚠️) ⸻ 🔹 🆚 Git vs GitHub • Git → CLI tool (local system) • GitHub → Web UI (remote repo hosting) ⸻ 💡 Pro Tip: Every developer should know this flow: 👉 Clone → Work → Push → Pull → Repeat This is how real companies work 🚀 #DevOps #Git #GitHub #Linux #VersionControl #100DaysOfDevOps #LearningJourney #Cloud #Automation #RealTime #frontlinemedia #flm #DevSecOps #MultiCloud