Mastering Git with SSH and GitHub Best Practices

🚀 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

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.

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

🚀 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

🚀 Git & GitHub Professional Workflow – Day 2 Most beginners use Git like a backup tool. That’s wrong. It’s a collaboration system, safety net, and tracking system. Here’s what actually matters: 🌐 Fork vs Clone Fork → Copy someone else's repo to your GitHub Clone → Download repo to your local machine If you don’t understand this clearly, you’ll struggle in real projects. ⚙️ Configuration Check your identity: git config --global --list Wrong name/email = messy commit history 🌿 Branching Strategy Never work directly on main Use: git checkout -b feature-name No branching = high risk of breaking code 🔁 Pull Request Workflow Commit changes Push code Create PR Get review Merge and delete branch Skipping review = poor engineering practice 📊 Important Commands git add . git status git commit -m "message" git pull origin main git branch 💡 Reality Check Most people don’t fail in DevOps because of AWS They fail because they don’t understand Git properly Big commits = bad practice Small commits = professional workflow Not pulling before pushing = conflicts Uploading secrets = serious mistake Vikas Ratnawat CloudDevOpsHub Community

If a change isn’t in Git, it didn’t happen. That’s not something I’m adopting for this build, it’s something I stopped tolerating. In it-re-dc01, everything lives in one place: Ansible roles. Terraform modules. Docker Compose stacks. Helm charts. Docs. Runbooks. ADRs. One repo: it-re-dc01-infra. GitHub Actions runs on a self-hosted runner on re01-mgmt-01. Every push triggers: • ansible-lint • docker compose validation • terraform validate Merges to main trigger applies. Terraform state is not local. It’s stored and secured via Vault-backed workflows. Secrets don’t live in the repo. They’re issued dynamically. Git defines the desired state. Vault secures access to it. GitHub Actions enforces the path to change. No manual changes. No exceptions. I’ve seen what happens without this discipline. At one point, we ran Jenkins where the pipeline configuration lived inside Jenkins itself. When Jenkins went down, the pipelines went with it. We rebuilt them from memory and screenshots and it took two weeks. That wasn’t a tooling issue, it was a process failure. The tool doesn’t matter, the discipline does. No change, no matter how small or urgent, happens outside the pipeline. Because if your system can’t be rebuilt from Git, you don’t control it. #GitOps #PlatformEngineering #CI/CD

🚀Day 34/90 Days DevOps Challenge - Introduction to Git & Basic Commands Today I completed Shell Scripting and started a new tool: Git & GitHub. This marks a shift from scripting to version control, which is a core part of DevOps. Git is a distributed version control system used to track and manage changes in source code efficiently. 🔹 What Git Helps With It tracks: • Who made the changes (author) • What changes were made • When the changes were made It solves major problems like collaboration, tracking code history, and maintaining backups. 🔹 History of Git Before Git, developers faced issues in collaboration and version tracking. Tools like BitKeeper were used but had limitations. Git was introduced by Linus Torvalds in 2005 as a free and open-source solution. 🔹 Git Workflow (Very Important Concept) Working Directory → Staging Area → Local Repository → Remote Repository Understanding this flow is critical. If you skip this, Git will always confuse you. 🔹 Core Git Operations • Adding → Move files to staging area • Committing → Save changes in local repo • Pushing → Upload code to remote repo • Pulling → Download latest changes 🔹 Basic Commands I Practiced • git init → Initialize a repository • git config user.name / user.email → Set identity • git add <file> → Add file to staging • git add . → Add all files • git status → Check file status • git commit -m "message" → Save changes • git log → View commit history • git remote add origin <url> → Connect to GitHub • git remote -v → Verify remote connection • git push origin master → Push code to GitHub 💡Key Learning Git is not about memorizing commands. It’s about understanding the flow of how code moves from your system to a shared repository. 📌 Tomorrow’s Topic: pulling, fetch & cloning in Git #90DaysOfDevOps #DevOps #CICD #Docker #Kubernetes #AWS #terraform #ansible #prometheus #grafana #CloudComputing #InfrastructureAsCode #LearningInPublic #FreshGraduate #CloudEngineer #Linux #Git #GitHub #VersionControl

🚨 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

Day 13 of my DevOps Journey. I broke a commit today. On purpose. And it fixed everything.🔥 Today I learned Git Reset and how to securely connect your server to GitHub - HTTPS vs SSH. First - The Real-World Problem that taught me Git Reset: Two developers. One repo. Dev1 had commits C1→C5. Dev2 added C6. Dev1 didn't pull C6 and made C7. Now Dev1 tries to push — ERROR. Why? Git expects order: C1, C2, C3, C4, C5, C6, C7. But Dev1 has C7 with no C6. The history is broken. The fix? Delete the commit, but keep the data. The command is "git reset --soft HEAD~1" C7 commit disappears. The work stays. Now pull C6 from Dev2. Recommit C7. Push succeeds.✅ Second — HTTPS vs SSH: Two ways to connect server to GitHub HTTPS → needs a token every time SSH → generate once, push forever HTTPS Token steps (short version): Profile → Settings → Developer Settings → Personal Access Tokens → Tokens (Classic) → Generate → select repo scope → copy to Notepad SSH Key steps: · ssh-keygen → press Enter 3 times · cd ~/.ssh then ll → you'll see two files · id_rsa = private key (stays on server) · id_rsa.pub = public key (goes to GitHub) · cat id_rsa.pub → copy the output · GitHub → Settings → SSH Keys → paste → done · Now push without credentials. Ever again. 🔑 —————————————— See you on Day 14 #DevOps #Git #GitHub #SSH #100DaysOfDevOps #Day13

🚀 Day 2 of my DevOps Journey — Getting serious about Git! Today I spent time going through a Git cheat sheet and it really clicked how powerful these commands actually are. Here's what I practiced: 📌 Setup & Init — git init, git clone 📌 Stage & Snapshot — git add, git commit, git diff, git reset 📌 Branch & Merge — git branch, git checkout, git merge 📌 Share & Update — git fetch, git pull, git push 📌 Rewrite History — git rebase, git reset --hard 📌 Temporary Commits — git stash, git stash pop, git stash drop One thing that really helped me understand Git visually? 👉 Visualizing Git (https://lnkd.in/gAyXGfti) You can type real Git commands and watch the commit tree update in real time. It's honestly one of the best free tools for building a mental model of how Git works under the hood. Git is not just a tool — it's a skill every DevOps engineer must master. One command at a time! 💪 #DevOps #Git #DevOpsJourney #Linux #VersionControl #LearningInPublic #ASD