Git Rollbacks & Diffs for Error Recovery

𝗗𝗮𝘆 𝟮𝟮 𝗼𝗳 𝗺𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 💻 Bringing code to life — cloned a Git repository to create a working copy for development 📥 𝗧𝗮𝘀𝗸: Clone Git Repository on Storage Server 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗼𝗱𝗮𝘆: • Difference between bare repository and working repository • How `git clone` creates a local working copy • Cloning repositories from local paths (not just GitHub) • Importance of using correct user permissions • Safe handling of shared repositories in production environments 𝗪𝗵𝗮𝘁 𝗜 𝗯𝘂𝗶𝗹𝘁 / 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱: • Logged into Storage Server (`ststor01`) as `natasha` • Verified existence of repository `/opt/games.git` • Created destination directory `/usr/src/kodekloudrepos` • Cloned repository using `git clone /opt/games.git` • Verified working copy using `git status` 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: • Understanding local path-based cloning • Ensuring no permission or structure changes were made • Being careful to use the correct user (`natasha`) 𝗙𝗶𝘅 / 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: • Learned that cloning from local repositories works the same as remote • Understood importance of maintaining repository integrity • Gained clarity on how working copies are used in development 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Cloning is where development begins — it bridges the gap between a central repository and actual coding work. This felt like a real-world Git workflow setup 🚀 Do you mostly clone from local repos, GitHub, or enterprise tools like GitLab/Bitbucket? #Day22 #DevOps #Git #VersionControl #Linux #Automation #CloudComputing #AWS #DevOpsJourney #LearningInPublic #100DaysOfDevOps

Some basics of git ========================================================= Working Area:  - the local directory on your computer where you can view and edit your project's files Staging Area (Index): You use the git add command to move specific changes from the working area to this intermediate "preparation" zone. Local Repository: You use git commit to permanently record the staged changes as a snapshot in the project's history. Common Commands git status: Shows which files in your working area have been modified but not yet staged, and which are untracked. git diff: Shows the exact line-by-line differences between your current working area and the staging area. git checkout -- <file>: Discards changes in your working area and restores the file to its last committed state. git stash - is a built-in Git command that temporarily saves your uncommitted changes so you can switch to a clean working directory without losing your work-in-progress. #git #github #jenkine #devops

𝗗𝗮𝘆 𝟯𝟮 𝗼𝗳 𝗺𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 💻 Keeping history clean — used Git rebase to update a feature branch without creating extra merge commits 🔄 𝗧𝗮𝘀𝗸: Git Rebase 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗼𝗱𝗮𝘆: • How `git rebase` helps maintain a clean, linear history • Difference between `merge` vs `rebase` • Why rebase avoids unnecessary merge commits • Importance of syncing feature branches with latest `master` • When to use force push after rebase 𝗪𝗵𝗮𝘁 𝗜 𝗯𝘂𝗶𝗹𝘁 / 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱: • Navigated to repo `/usr/src/kodekloudrepos/games` • Switched to feature branch • Pulled latest changes from `master` • Rebased feature branch using `git rebase origin/master` • Resolved conflicts (if any) • Verified clean commit history using `git log` • Pushed updated branch using `git push --force` 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: • Understanding difference between merge and rebase • Handling conflicts during rebase • Knowing when force push is required 𝗙𝗶𝘅 / 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: • Learned that rebase rewrites commit history • Understood why it creates a cleaner project timeline • Gained clarity on resolving conflicts step-by-step • Realized rebase is widely used in professional workflows 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Rebase isn’t just about updating branches — it’s about keeping your Git history clean and readable. This felt like working with real-world collaborative Git workflows 🚀 Do you prefer using rebase or merge in your projects — and why? #Day32 #DevOps #Git #VersionControl #Linux #Automation #CloudComputing #AWS #DevOpsJourney #LearningInPublic #100DaysOfDevOps

I just went from zero Git knowledge to a full branching workflow — here's every command you need to know Save this. I wish I had this when I started. ━━━━━━━━━━━━━━━━━━━━━━ CORE COMMANDS — use these every day → git init ............... Start a new repo → git add . .............. Stage all changes → git commit -m "msg" .... Save a snapshot → git push origin main ... Push to GitHub → git status ............. See what changed → git log --oneline ...... View commit history ━━━━━━━━━━━━━━━━━━━━━━ BRANCHING — how real teams work → git branch dev ......... Create a new branch → git checkout -b dev .... Create + switch → git merge dev .......... Merge into main → git branch -d dev ...... Delete a branch → git mv old.txt new.txt . Move / rename file → git rm file.txt ........ Delete a file ━━━━━━━━━━━━━━━━━━━━━━ PROFESSIONAL DEV WORKFLOW 1️⃣ Create a feature branch 2️⃣ Write your code 3️⃣ Commit often with clear messages 4️⃣ Merge or open a Pull Request ━━━━━━━━━━━━━━━━━━━━━━ Golden rule: Never work directly on main. Always create a feature branch. This is how every professional team operates — and it will save you countless headaches. It took me a while to get comfortable with all of this — but now Git feels like second nature. If you're just starting out, take it one command at a time. Consistency beats speed every time. Are you learning Git right now? Drop a comment below — let's connect! #Git #Ubuntu #Linux #100DaysOfCode #OpenSource #Developer #WebDevelopment #SoftwareEngineering #CodingLife

Day 32/100: Creating Parallel Universes – Git Branching & Merging 🌿 Today’s Focus: Up until now, all my Git commits have been on a single, straight timeline. But what if I want to experiment with a risky new feature or write a new automation script without breaking the working production code? Today, I learned the solution: Git Branching! 🧠 What is a Branch? A branch in Git is essentially an independent line of development. It allows you to create a "parallel universe" of your project. You can build, break, and test things in this isolated branch, and the main project remains completely untouched. 🛠️ The Core Workflow I Practiced: git branch: Used to list all the branches in my repository and see which one I am currently working on. git checkout -b [branch-name]: The ultimate shortcut command! This creates a brand new branch and instantly switches me over to it. I used this to create a safe space for testing a new script. git merge [branch-name]: The moment of truth. Once my experimental feature was working perfectly, I switched back to the main branch and used this command to seamlessly combine my new code into the primary project timeline. Why It Matters: In a DevOps team, you never push unverified code directly to the main branch. Branching allows dozens of engineers to work on the exact same project simultaneously, completely isolated from one another, before safely merging their features together. It is the backbone of modern team collaboration! 🤝 #100DaysOfDevOps #100DaysOfCode #Git #VersionControl #Linux #Branching #SysAdmin #DevOpsEngineer #TechJourney #DailyProgress #CloudComputing

🚀 Git Branching Strategies – The Backbone of Clean & Scalable Development In any DevOps or software development lifecycle, having the right Git branching strategy is crucial for maintaining code quality, enabling collaboration, and ensuring smooth deployments. Here are some of the most important branching strategies every developer should know 👇 🔹 1. Git Flow A structured approach with dedicated branches like main, develop, feature, release, and hotfix. ✔ Best for large teams & release-based projects 🔹 2. Feature Branching Each feature is developed in its own branch and merged back after completion. ✔ Keeps main branch stable ✔ Encourages parallel development 🔹 3. Trunk-Based Development Developers commit frequently to a single branch (main/trunk). ✔ Ideal for CI/CD environments ✔ Faster integrations, fewer merge conflicts 🔹 4. Release Branching Separate branches created for preparing production releases. ✔ Stabilizes code before deployment ✔ Allows ongoing development in parallel 🔹 5. Forking Workflow Common in open-source projects where contributors fork repositories. ✔ Enhances security and collaboration #AWS #CloudDevOPs #Linux #CI/CD #Docker #EKS #Kubernetes #Terraform #Jenkins #Harness #Monitoring Tools #Git #Github #python

Week 3 done. This one hit different. Git isn't just commands—it's how real teams collaborate without breaking production. I simulated a complete Git Flow this week: feature branches, release branches, hotfix workflows. Seeing that full branch graph with merges, tags, and proper history was satisfying. Then came Day 11. My first comprehensive exam covering everything from Linux to Git. Twenty questions, ten hands-on tasks, real-world scenarios. Passed with 90%. But here's what mattered more: when the exam had questions on topics we hadn't covered, I called it out. Not rudely, just directly. My teacher listened, apologized, and changed the rule: "Only test what's been taught." Small win, but it felt important. Quick wins this week: Resolved my first merge conflict (those <<<<<<< markers make sense now) Learned git stash for context switching Ran a complete hotfix simulation (v1.0 → v1.0.1) 36+ scripts now on GitHub My portfolio is live at https://lnkd.in/ggFmPwEm. Next week: Docker. If you're learning DevOps—don't just watch tutorials. Break things. Fix them. Document it. That's where learning happens. #DevOps #Git #LearningInPublic #DevOpsJourney #CareerTransition

Day 31/100: Time Traveling with Git – Basic Versioning ⏳ Today’s Focus: Yesterday, I learned how to save my work using git commit. But what happens when you actually need to use those saved snapshots? Today, I dove into Basic Versioning in Git to understand how to read project history and navigate between different versions of my code. 🧠 The Core Concept: The Commit Hash Every time you make a commit in Git, it generates a unique 40-character alphanumeric ID called a SHA-1 hash (e.g., a1b2c3d...). This hash is the exact coordinates of that specific version of your project in time! 🛠️ The Commands I Mastered: I practiced exploring my repository's history and moving through time: git log: The ultimate project diary. This command lists out the entire timeline of commits, showing who made the change, when they made it, the commit message, and that all-important commit hash. git log --oneline: A cleaner, condensed version of the log that makes it much easier to read when you have dozens of commits. git show [commit-hash]: Zooming in on a specific moment. This shows me exactly which lines of code were added or deleted in that particular commit. git checkout [commit-hash]: The time machine! Running this command changes the files in my working directory to look exactly as they did at that moment in the past. Why It Matters: In a DevOps or development environment, code breaks. It is inevitable. Versioning means that if a new script or application update crashes the system, I don't have to panic or try to remember what I changed. I can simply look at the git log and safely roll the project back to the last known working state. It is the ultimate "undo" button! 🔄 #100DaysOfDevOps #100DaysOfCode #Git #VersionControl #Linux #SysAdmin #DevOpsEngineer #TechJourney #DailyProgress #CloudComputing #CodingLife

Going from git push to a live production container - all on my own hardware. 🛠️ I recently shared a project I built for media processing. While the app itself was fun, deploying updates to my self-hosted environment was painful: manually build and push a new docker file, SSH into the server, pull the new image, spin up the new container. I wanted to streamline this process with professional-grade CI/CD pipeline, this was the real playground. The Pipeline: 1.  Version Control: Code pushed to GitHub. 2.  CI: GitHub Actions triggers an Ubuntu VM to build from my Dockerfile. 3.  Registry: The fresh image is pushed to my public Docker Hub repository. 4.  The "Handshake": GitHub Actions hits a custom Webhook Server I wrote running on my home lab. 5.  CD: My server pulls the latest image and restarts the container automatically. Was a full CI/CD pipeline necessary for a tool used by exactly two people? Probably not. But building it taught me more about the "plumbing" of DevOps - like handling GitHub actions, securing all my secrets!! webhooks and Docker registries - core concepts i can apply to future development, all while having fun building something simple. And most importantly, removing friction from my own workflow with one-click deployment. The biggest hurdle? It wasn't the Webhook server or the Docker orchestration. It was spending longer than i care to admit figuring out why my test downloads were "corrupted" on my Linux machine, only to realize I just needed to install VLC to support the MP4/MKV codecs. Sometimes the "bug" is just your media player! 😂 It’s not just about the final tool; it’s about having a playground to break things and fix them. #DevOps #Docker #GithubActions #SelfHosted #HomeLab #BackendEngineering

Git is more than just a tool — it's the heartbeat of every DevOps pipeline. 💓 After covering Linux fundamentals, I went deep on Git. Not just reading docs — I practiced 23 essential commands hands-on, documenting every terminal output and GitHub workflow along the way. 🛠️ 📚 What's inside the hands-on guide? 1️⃣ Foundation — Installation on Ubuntu + identity setup with git config. 2️⃣ Core Workflow — Mastering the flow: Working Directory → Staging → Local Repo → Remote. 3️⃣ Branching — Managing dev and prod branches like a professional environment. 4️⃣ Recovery Tools — git stash for work-in-progress and git cherry-pick for surgical fixes. 5️⃣ History Control — Knowing exactly when to use --soft vs --hard reset. 💡 3 things I learned by intentionally breaking Git: The Golden Rule: 1. Always pull before you push. I triggered a push rejection on purpose — by adding a file directly on GitHub — and resolved the conflict step by step. That 10 minutes taught me more than hours of reading. 2. Visualize the tree. git log --oneline --graph is your best friend. If you can’t see the branch structure, you don’t truly control the flow. 3. Commit with intent. Small, frequent commits with clear messages beat one massive "final update" every time — especially when something breaks and you need to roll back. I'm sharing the wealth! 👇 Attached major command reference guide with real terminal screenshots and GitHub workflow documentation. I hope this helps anyone else on the DevOps path. #Git #GitHub #DevOps #VersionControl #Linux #CloudComputing #LearningInPublic #Automation #SoftwareEngineering #TechSkills