Git & GitHub: Restore, Reset & Force Push Best Practices

🚀 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

Day 30 - Git Hard Reset #100DaysOfDevOps🧑💻 Today’s task focused on rewriting Git history in a controlled environment. A skill that directly translates to real-world production support. The Nautilus team had a test repository where multiple temporary commits were pushed. The requirement was clear: clean up the repository so only two commits remain in history with both the branch pointer and HEAD aligned to one of the commits. To achieve this, I navigated to the repository, identified the correct commit using "git log --oneline", and executed a "git reset --hard commit-hash" to move the branch pointer and HEAD back to the required state while cleaning the working tree. Since this rewrites commit history, I followed up with a "git push --force" to update the remote repository safely. This reflects real production scenarios where accidental commits, sensitive data exposure, or test changes must be surgically removed while keeping repository integrity intact. Understanding when and how to rewrite history, and the risks involved, is critical in DevOps and release engineering workflows. Full documentation and command breakdown available here: https://lnkd.in/g-HZxwzw Another solid step forward. Excited to tackle tomorrow’s challenge and keep building production-ready Git expertise. 🚀 #DevOps #Git #VersionControl #CloudEngineering #SRE #Linux #ContinuousLearning

🚀 Understanding Git Workflow – Simple & Clear Today I revised the complete Git workflow, covering all key areas from clone to push 👇 🔹 Git Areas Explained 1️⃣ Remote Repository (GitHub / GitLab) This is the central repository where the project code is stored online and shared with the team. 2️⃣ Local Repository (.git folder) A copy of the remote repository on your local machine. All commits are permanently stored here. 3️⃣ Working Directory This is where you edit files and write code. Changes here are not tracked until you add them. 4️⃣ Staging Area (Index) A temporary area where you prepare changes before committing. It helps control what goes into the next commit. 🔄 Git Commands Flow git clone → Copies the remote repository to your local machine git add → Moves changes from Working Directory to Staging Area git commit → Saves staged changes to the Local Repository git push → Sends commits from Local Repository to Remote Repository git pull → Fetches latest changes from Remote Repository to Local 🎯 One-Line Summary Code is written in the Working Directory, staged carefully, committed locally, and finally pushed to the remote repository for collaboration. #Git #GitWorkflow #GitHub #DevOps #VersionControl #LearningJourney #SoftwareEngineering

🚀 Day 6 – Git & GitHub Series | Reverting & Resetting (Undo Like a Pro) Let’s be honest… Every developer has done this at least once: 👉 committed wrong code 👉 deleted a file by mistake 👉 pushed something broken 👉 or thought “How do I go back now?!” 😅 That’s where Git recovery commands save your life. Because in real projects, it’s not about never making mistakes — it’s about fixing them safely and fast. 🔹 Must-know Undo Commands ✅ Move HEAD but keep changes git reset --soft <commit_id> ✅ Unstage changes git reset --mixed <commit_id> ✅ Reset everything (⚠ dangerous) git reset --hard <commit_id> ✅ Safely undo via new commit (team-friendly) git revert <commit_id> ✅ Restore files git restore <file> ✅ Remove from staging git restore --staged <file> ✅ Clean unwanted files git clean -f git clean -fd 💡 Real-world rule I follow ✔ Working alone → reset ✔ Working in team/shared repo → revert ✔ Avoid --hard unless 100% sure ✔ Always double-check before cleaning Small knowledge → Huge time saved during production issues. 📌 This is Day 6 of my Git Mastery Series Daily practical Git + GitHub tips for Developers, DevOps & SREs. If you’re serious about leveling up your engineering skills: 👉 Follow for the next post #Git #GitHub #DevOps #SRE #VersionControl #SoftwareEngineering #Developers #ProgrammingLife #TechLearning #CloudComputing #Debugging #OpenSource #CareerGrowth #LearnInPublic

🚀 From Shell Scripts to Git Commits — Building My DevOps Foundation (Day 21 & 22) Two days. Two core skills. One powerful shift in mindset. 🔥 🧠 Day 21 – Shell Scripting Cheat Sheet: Build Your Own Reference Guide Instead of just writing more scripts… I built something I’ll use for years. 👉 A personal Shell Scripting Cheat Sheet What I included: Variables & user input If-else conditions Loops (for / while) Functions Exit codes Real automation snippets Common mistakes & fixes 💡 Biggest lesson: If you can organize and explain it clearly, you truly understand it. Automation isn’t just about writing scripts. It’s about writing scripts with clarity and confidence. 🔥 Day 22 – Introduction to Git: My First Repository Then I stepped into version control with Git — the backbone of modern DevOps. Today I: ✅ Installed & configured Git ✅ Created my first repository ✅ Explored the hidden .git/ folder ✅ Built git-commands.md (my growing Git reference) ✅ Made multiple clean commits ✅ Understood the workflow deeply Working Directory → Staging Area → Repository Now I understand: Why git add exists What the staging area actually does Why clean commit history matters Git doesn’t just track files. It tracks growth. 🎯 What These Two Days Taught Me 🔹 Documentation strengthens memory 🔹 Automation needs discipline 🔹 Version control protects your progress 🔹 Small daily improvements compound fast Shell scripting taught me to automate. Git taught me to manage change. That’s real DevOps thinking. 🚀 Let’s learn together 👇 #DevOps #Git #ShellScripting #Linux #Automation #90DaysOfDevOps #LearningInPublic #DevOpsKaJosh #TrainWithShubham

🚀 Day 34 of #100DaysOfDevOps with #KodeKloud 🚀 Today's challenge was all about Git Hooks 🧠 Need to Know Git provides a way to trigger custom scripts when certain important actions occur. There are two types of hooks: client-side and server-side. 🔹 Client-side: triggered by operations such as committing and merging 🔹 Server-side: triggered by network operations such as receiving pushed commits To install a hook, you just need to rename it by removing .sample from its name in the .git/hooks directory The task was to create a post-update hook to generate a release tag for each push. The post-update hook runs right after a push is completed on the remote repository. Here's How I Did It: 🔹 Merged the feature and master branches in the repository 🔹 Went to the remote repository (/opt/ecommerce.git), accessed the Git hooks, and updated the post-update hook by removing .sample from its name and changing its content to: #!/bin/bash if [ "$1" = refs/heads/master ]; then echo "Creating release tag" git tag release-date '+%Y-%m-%d' master fi 🔹 Went back to the local repository and pushed the changes 🔹 Tested the release tag in the remote repository using git tag 🔹 Verified the tag release-2026-02-05 💡 Key Takeaways: ✅ Since this specific hook is a server-side one, the configuration and script must be in the remote repository, not the local one (took me a while to figure that out!). ✅ There are many other useful hooks as well, such as: 🔸pre-commit: runs first, before you even type a commit message. 🔸post-commit: runs after a commit is made. often used for notifications or similar tasks. 🔸 post-merge: runs after a successful merge. It can be used to restore data that Git doesn't track, such as file permissions. …and many others that perform specific tasks at different stages of the Git workflow. Have a good Day, everyone! 🦬 #GitHooks #DevOps #AutomationScripting

This is post 2 of 3 🚨 We Rewrote Git History to Remove a Secret. Here’s What Broke. A Gmail password was accidentally committed in a `.env` file. First step?   👉 We rotated the password immediately. Because here’s the truth: If the primary secret is not actively being exploited,   rotating it is often enough. Rewriting Git history should NOT be your first reaction. 💥 When We Decided to Rewrite History We used `git filter-repo` and force pushed. That fixed the repository history. But here’s what changed 👇 `A → B → C → D → E` became `A → B → C' → D' → E'` Every commit after the change got a new hash. ❌ What Broke? • Team couldn’t pull → everyone re-cloned   • CI/CD pipelines referencing old SHA failed   • Open PRs needed rebase/recreation   • Commit references in Jira became invalid ✅ So What’s the Right Approach? If a secret is committed: 1️⃣ Rotate it immediately   2️⃣ Assess impact   3️⃣ Rewrite history only if risk remains Because rewriting Git history is powerful —   but it affects your entire team. 💡 Lesson for SDETs & DevOps Engineers Security is priority. But controlled impact is also engineering maturity. Sometimes rotating the secret is enough.   Sometimes rewriting history is necessary. Knowing the difference is real experience. #SDET #AutomationTesting #Playwright #APITesting #DevOps #Git #CI_CD #SecureCoding #QualityEngineering

🚀 Day 11 of Git & GitHub Mastery – Submodules (Manage External Repos Like a Pro) As projects grow… one repository is rarely enough. Shared libraries. Common utilities. Reusable services. Copy-pasting code? ❌ Professional teams use Git Submodules ✅ Submodules let you embed and manage external repositories inside your main project — cleanly, versioned, and controlled. Today’s essentials: ✅ git submodule add → Add external repo ✅ git submodule init → Initialize after clone ✅ git submodule update → Sync to correct commit ✅ git submodule status → Track versions ✅ git submodule update --remote → Pull latest ✅ git submodule foreach → Run commands across all 💡 Why this matters: • Better code reuse • Separate version control • Cleaner architecture • Production-grade dependency management This is how real enterprise projects manage shared components. If you’re aiming for Senior Dev / DevOps / Platform Engineer roles, Submodules are a skill you shouldn’t skip. 📌 Save this post 📌 Try adding one submodule today 📌 Follow the series for Day 12 Level up your Git. Level up your career 🚀 #Git #GitHub #DevOps #SoftwareEngineering #BackendDevelopment #DeveloperTools #CodingLife #TechSkills #OpenSource #VersionControl #SystemDesign #EngineeringLife #LearnInPublic #BuildInPublic #100DaysOfCode

My GIT - Cheat sheet 𝐏𝐫𝐨 𝐭𝐢𝐩 - To learn Git better, ditch the GUI and use the command line. 𝐖𝐡𝐚𝐭? A distributed version control system that tracks changes in files over time. 𝐖𝐡𝐲? Enables collaboration, branching, merging and a complete project history. 📌 𝐊𝐞𝐲 𝐓𝐞𝐫𝐦𝐢𝐧𝐨𝐥𝐨𝐠𝐢𝐞𝐬 - ◾ Repository A directory containing your project's complete history. ◾ Working Directory The current state of your project files. ◾ Staging Area (Index) Where you prepare changes for the next commit. ◾ Commit A snapshot of your project at a specific point in time. ◾ Branch A separate line of development. Remote: A version of your repository hosted on a server (e.g., GitHub, GitLab). 📌 𝐆𝐢𝐭 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 [1.] Commit Early, Commit Often ◾ Don't let changes pile up. ◾ Commit frequently to create smaller, more manageable snapshots of your work. ◾ This makes it easier to track progress, identify issues and revert if needed. [2.] One Change per Commit ◾ Keep your commits focused on a single logical change or feature. ◾ This improves readability and makes it easier to isolate and revert specific changes. [3.] Clear Commit Messages ◾ Write concise yet descriptive commit messages that explain what you changed and why. ◾ This makes it easier for you and your collaborators to understand the purpose of each commit in the future. ◾ Include some change or ticket # [4.] Merge or Rebase ◾ Use git merge to combine branches, or git rebase to apply your changes on top of another branch. ◾ Choose the method that best suits your workflow and preferences. [5.] Delete Merged Branches ◾ Once a branch has been merged, delete it to keep your repository tidy and avoid confusion. [6.] Pull Regularly ◾ Always fetch and merge the latest changes from the remote repository before starting new work. ◾ This helps avoid conflicts and keeps your local repository in sync with your team. [7.] Code Reviews ◾ Use pull requests or similar mechanisms to get feedback on your changes before merging them into the main branch. ◾ Code reviews help catch errors, improve code quality and ensure consistency across the codebase. [8.] Resolve Conflicts Carefully ◾ If conflicts arise when merging branches, resolve them carefully and thoroughly. ◾ Test your changes after resolving conflicts to ensure everything works as expected. git commit -m "works on my machine" 🙂 Follow Mayank for more such insights.

Every developer uses Git daily. Almost none of them know what actually happens when they type git commit. Let me explain it in under 2 minutes: Step 1: The Flow Your files live in a Working Directory. git add copies them to a Staging area. git commit takes a snapshot. git push sends it to the remote. That's it. That's the daily workflow. Step 2: What's actually inside .git Every commit stores a complete snapshot of your project, not just the changes. Git identifies everything using SHA hashes: a 40-character fingerprint generated from the file content. If two files are identical, they get the same hash and Git only stores one copy. That's why Git is so fast. Step 3: Branches are embarrassingly simple A branch is a text file. Inside it? One line: a commit hash. main points to your latest commit. HEAD points to your current branch. When you create a new branch, Git writes a single file. Done. No magic. Just snapshots, hashes, and pointers. ------------------ 👉 Send in that connection, if you want to see more tech concepts simplified on your feed. ♻️ Repost if you found it valuable! #Git #AIEngineering #Tech