Mastering Git for DevOps: Essential Commands and Best Practices

🚀 Git Deep Dive: Revert, Branching & Merging Concepts (Real DevOps Perspective) In real-world DevOps, Git is not just about commits—it’s about control, safety, and collaboration. Let’s break down some of the most important concepts: 1. Git Revert 2.Branching 3. Merging 👇 1.🔁 GIT REVERT (Safe Undo Mechanism) One of the most powerful and safe ways to undo changes in Git. 👉 What it does: Reverses a specific commit Creates a new commit that undoes previous changes Keeps history intact (very important in teams) 📌 Syntax: git revert <commit_id> 🔥 Why it’s important: No history deletion Safe for shared branches Ideal for production fixes 👉 DevOps Insight: Always prefer git revert over reset when working in shared repositories or CI/CD pipelines. 2.🌿 GIT BRANCHING (Core of Parallel Development) A branch is an independent line of development. 👉 It allows you to: Work on features without affecting main code Fix bugs independently Collaborate efficiently ⚠️ Default branch name used to be master, but now most projects use main. ⚙️ BRANCH COMMANDS (Must Know) 📌 List branches git branch 📌 Create a branch git branch feature-name 📌 Switch branch git checkout feature-name 📌 Create + switch (shortcut) git checkout -b feature-name 📌 Rename branch git branch -m old-name new-name 📌 Delete branch (safe) git branch -d branch-name 📌 Force delete branch git branch -D branch-name 📌 Recover deleted branch git branch branch-name <commit_id> ⚠️ -d vs -D (Interview Favorite) -d → Deletes only if branch is merged -D → Force delete, even if not merged 👉 Use -D carefully—can lead to data loss if misused. 3.🔀 GIT MERGE (Combining Work) Git merge is used to combine changes from one branch into another. 📌 Syntax: git merge branch_name 🔥 Example Workflow: Work on feature-branch Switch to main Merge changes ⚔️ What Happens During Merge? Git compares histories Applies changes Creates a merge commit (if needed) 💥 Merge Conflicts (Real-World Scenario) Occurs when: 👉 Same file + same lines modified in different branches Example: <<<<<<< HEAD Your changes ======= Incoming changes >>>>>>> branch-name ✅ Resolution: Manually fix code Remove conflict markers Commit changes 🧠 DevOps Best Practices ✔ Use feature branches (feature/*) ✔ Never commit directly to main ✔ Use git revert instead of rewriting history ✔ Always pull latest code before merge ✔ Keep branches short-lived 👉 Combine Git with CI/CD: Branch → triggers pipeline Merge → deploys to staging Tag → triggers production release 🎯 Final Thoughts Mastering Git is not about remembering commands— It’s about understanding how to safely manage code in a team environment.

🚀 GitHub for DevOps – Day 3 (Part 2) Master Git Tags & Branching Strategy (Real-World Usage) In real-world DevOps, Git is not just about pushing code — it’s about managing releases, ensuring stability, and enabling smooth deployments. Let’s break down two critical concepts every DevOps Engineer must know 👇 🔖 1. Git Tags – Version Control Made Simple A Git tag is a label assigned to a specific commit. It helps you mark important points in your project history. 👉 Example: commit1 → commit2 → commit3 → commit4 You mark commit3 as v1.0 ✔️ git tag v1.0 Now commit3 = Release Version 1.0 🎯 Why Tags Matter ✔️ Versioning v1.0 → Initial release v1.1 → Bug fixes v2.0 → Major update ✔️ Easy Rollback git checkout v1.0 ✔️ Deployment Trigger CI/CD tools trigger pipelines based on tags ⚙️ Common Commands ✔️ Create Tag git tag -a v1.0 -m "Release version 1.0" ✔️ List Tags git tag ✔️ Push Tag git push origin v1.0 📌 Where Tags Are Used Production releases CI/CD pipelines (Jenkins, GitHub Actions) Version tracking Deployment automation ⏱️ When to Use Tags Feature is complete Code is stable You are releasing a new version ⚠️ Important Rule: Tags are immutable (should not be changed once created) ---------------------------------------------------------------- 🌿 2. Git Branching Strategy (Industry Standard) A clean branching strategy keeps your codebase organized and production safe. main (production) │ |── develop (integration) │ ├── feature/login │ ├── feature/payment │ |── release/v1.0 │ |── hotfix/bug-123 🔹 Branch Roles Explained main Live production code Always stable develop Integration branch Used for testing (QA/Staging) feature/* Created by developers Example: feature/login Merged into develop after completion release/* Pre-production testing Final validation before release hotfix/* Emergency fixes Directly applied to production 🏢 Common Company Rules ✔️ Never push directly to main ✔️ Always use Pull Requests ✔️ Code review is mandatory ✔️ CI/CD pipelines run automatically 💡 Final Thought If you want to work in real production environments, understanding Git tags + branching strategy is not optional — it’s essential. These concepts directly impact: ✔️ Deployment reliability ✔️ Release management ✔️ Team collaboration #DevOps #Git #GitHub #CICD #Jenkins #Cloud #SoftwareEngineering #TechCareers

🚀 Deep Dive into Git: Tags, Forks, Merge Conflicts & Bitbucket As part of DevOps and version control, There are some essential Git concepts that play a critical role in real-world development workflows. Here’s a detailed breakdown 👇 🔖 1. Git Tags – Managing Releases Efficiently Git tags are used to mark specific points in the repository history, typically to represent stable releases like v1.0, v2.0. There are two types of tags: ✔️ Lightweight Tags – Simple references to a commit ✔️ Annotated Tags – Include metadata like author name, date, and message 📌 Why Tags Matter: Help in release management Provide easy rollback points Widely used in CI/CD pipelines for deployments 💻 Common Commands: git tag v1.0 → Create tag git tag -a v1.0 -m "First release" → Annotated tag git push origin v1.0 → Push tag 🍴 2. Fork – Working Independently on Projects Forking allows you to create your own copy of a repository, enabling you to experiment or contribute without affecting the original project. This concept is commonly used in platforms like Bitbucket for open-source contributions. 📌 Typical Fork Workflow: 1️⃣ Fork the repository 2️⃣ Clone it to your local system 3️⃣ Create a new branch 4️⃣ Make changes and commit 5️⃣ Push changes to your fork 6️⃣ Create a Pull Request (PR) 🎯 Use Cases: Open-source contributions Safe experimentation Learning from real-world projects ⚔️ 3. Merge Conflicts – Handling Code Conflicts Merge conflicts occur when multiple developers modify the same lines of code or related parts of a file. Git cannot automatically decide which change to keep. 📌 How Conflicts Look: <<<<<<< HEAD Code from main branch ======= Code from feature branch >>>>>>> feature 🔧 Steps to Resolve Conflicts: ✔️ Check status using git status ✔️ Open the conflicted file ✔️ Manually edit and keep correct code ✔️ Remove conflict markers ✔️ Stage and commit changes 💡 Best Practices: Pull latest changes before starting work Commit frequently Keep branches small and focused Communicate with team members 🔀 4. Bitbucket – Git-Based Collaboration Platform Bitbucket is a Git repository hosting service that enables teams to collaborate efficiently. 🌟 Key Features: Repository hosting Pull requests & code reviews Branch permissions Integration with CI/CD pipelines Secure access control 📌 Basic Workflow in Bitbucket: 1️⃣ Create repository 2️⃣ Clone repository 3️⃣ Create feature branch 4️⃣ Make changes & commit 5️⃣ Push code 6️⃣ Create Pull Request 7️⃣ Review & merge 💼 Real-World Development Scenario In a team environment: Developers work on separate feature branches Code is pushed to remote repositories Pull Requests are created for review Merge conflicts (if any) are resolved Stable versions are tagged (e.g., v1.0) Code is deployed via CI/CD pipelines Mastering Git concepts like Tags, Forks, Merge Conflicts, and platforms like Bitbucket is essential for: ✔️ Efficient collaboration ✔️ Clean version control ✔️ Faster and safer deployments

🚨 GitHub for DevOps – Day 4 (Part 3) “Pushed to the wrong branch? Here’s how professionals fix it.” Mistakes in Git happen — even in production teams. What matters is how you recover safely without breaking the workflow. ⚠️ Scenario A developer accidentally pushes code to the staging branch instead of their feature branch. hitesh-fs (local) ↓ feature-staging ↓ staging ❌ (wrong push) ↓ main-staging ↓ main Now the question is: 👉 How do we fix this without impacting the team? 🧠 First Rule (Critical Decision) Before doing anything, ask: 👉 Has anyone already used/pulled the staging branch after your push? This decides your solution 👇 ✅ Case 1: No one used it yet (Safe to rewrite history) Use RESET (Clean Solution) 🔧 Steps: 1️⃣ Check commit history git log --oneline 2️⃣ Reset staging to previous state git checkout staging git reset --hard <previous-commit-id> 3️⃣ Push changes to remote git push --force origin staging 💡 Why force push? Because reset only updates your LOCAL branch 👉 Remote (GitHub) still has the wrong commit 👉 Force push syncs it back to the correct state 🎯 Result: ✔ Wrong commit removed ✔ Branch restored cleanly ⚠️ Case 2: Team already used staging (DO NOT RESET) Use REVERT (Safe for teams) 🔧 Steps: 1️⃣ Identify wrong commit git log --oneline 2️⃣ Revert the commit git revert <wrong-commit-id> 3️⃣ Push changes git push origin staging 🎯 Result: ✔ Git creates a new commit that cancels the mistake ✔ No history rewrite (safe for collaboration) 📊 Visual Understanding Before mistake: A → B → C After wrong push: A → B → C → D ❌ ✔ Using RESET: A → B → C ✅ ✔ Using REVERT: A → B → C → D → E (undo D) 🔐 What about your feature branch? 👉 Your code in hitesh-fs is still safe 👉 No changes required there ✅ 🔥 Pro Tips (Real DevOps Practice) ✔ Always verify your branch before pushing git branch ✔ Prefer safe push: git push origin hitesh-fs ❌ Avoid: git push origin staging 🚀 Final Takeaway 👉 RESET = Clean but risky (use only if no one pulled) 👉 REVERT = Safe and team-friendly (preferred in real environments) Mistakes are part of engineering. Controlled recovery is what defines a strong DevOps Engineer. ⚡ #HiteshDevOps #DevOps #Git #GitHub #CI_CD #Docker #Kubernetes #AWS #OpenToWork #HiringDevOps #DevOpsEngineer #TechHiring   #LearningInPublic #BuildInPublic #TechJourney

💻 GitHub for DevOps – Day 4 (Part 4) 🚨 Accidental Push to Staging? Handle It Like a Pro Mistakes in Git are not rare — they’re expected. What matters in real DevOps environments is how safely and quickly you recover without impacting others. ⚠️ Real Scenario A developer is working on a feature branch: hitesh-fs ↓ feature-staging ↓ staging ❌ (wrong push happened here) ↓ main-staging ↓ main 👉 Code was mistakenly pushed into staging Now the challenge is: Fix it without breaking your team’s workflow 🧠 First Rule (Critical Decision) Before fixing anything, ask: 👉 Has anyone already used/pulled the staging branch? This decides your approach 👇 ✅ Method 1: REVERT (Safe – Recommended in Companies) ✔ Use when: Team has already pulled the code Branch is shared (staging/main) 🔧 Steps: 1️⃣ Find the wrong commit git log --oneline 2️⃣ Revert the commit git revert <commit-id> 3️⃣ Push changes git push origin staging 🎯 What happens? ✔ Git creates a new commit that cancels the mistake ✔ History remains intact ✔ Safe for team collaboration ⚠️ Method 2: RESET (Use Carefully) ✔ Use when: No one has pulled the changes You want a clean history 🔧 Steps: 1️⃣ Identify previous commit git log --oneline 2️⃣ Reset branch git reset --hard <old-commit-id> 3️⃣ Force push git push --force origin staging 🎯 What happens? ✔ Wrong commit is completely removed ✔ Branch goes back to previous state ❗ History is rewritten (risky in teams) 📊 Visual Understanding Before mistake: A → B → C After wrong push: A → B → C → D ❌ ✔ Using REVERT: A → B → C → D → E (undo D) ✔ Using RESET: A → B → C ✅ 🔐 Real DevOps Rule For branches like: 👉 staging / main ✅ Always prefer: git revert Because: 👉 Team safety > Clean history 🔥 Pro Tip (Avoid This Mistake) Before every push: git branch 👉 Ensure you're on: ✔ hitesh-fs NOT: ❌ staging 🚀 Final Takeaway ✔ Mistakes happen in Git ✔ Revert keeps your team safe ✔ Reset should be used with caution 👉 A strong DevOps Engineer is not the one who avoids mistakes — but the one who handles them safely in production environments. #HiteshDevOps #DevOps #Git #GitHub #CI_CD #Docker #Kubernetes #AWS #OpenToWork #HiringDevOps #DevOpsEngineer #TechHiring #LearningInPublic #BuildInPublic #TechJourney

Day 29 Of DevOps 🚀 All Important Bitbucket Commands (Git + CLI + Pipelines) Bitbucket is built on top of Git, so most Bitbucket operations use Git commands. Below is a complete practical command reference for DevOps engineers 👇 🔹 1️⃣ Repository Setup git clone https://lnkd.in/gCKqsdNX git init git remote add origin <repo-url> git remote -v 🔹 2️⃣ Basic Workflow Commands git status git add . git add <file> git commit -m "PROJ-101 added login API" git push origin main git pull origin main git fetch origin 🔹 3️⃣ Branching Commands git branch git branch feature/PROJ-101-login git checkout feature/PROJ-101-login git checkout -b bugfix/PROJ-102-timeout git switch main git merge feature/PROJ-101-login git branch -d feature/PROJ-101-login 🔹 4️⃣ Tagging (Releases) git tag git tag v1.0.0 git push origin v1.0.0 🔹 5️⃣ Undo / Reset Commands git reset --soft HEAD~1 git reset --hard HEAD~1 git revert <commit-id> git checkout -- <file> git reflog 🔹 6️⃣ Stashing Changes git stash git stash list git stash apply git stash pop 🔹 7️⃣ Pull Request (CLI via REST API Example) Bitbucket PRs are usually created via UI, but can also be created using API: curl -X POST -u username:app_password \ https://lnkd.in/gAaPDwSS \ -d '{"title": "PR for PROJ-101", "source": {"branch": {"name": "feature/PROJ-101-login"}}, "destination": {"branch": {"name": "main"}}}' 🔹 8️⃣ Bitbucket Pipelines Commands Bitbucket uses a bitbucket-pipelines.yml file in the repo root. Example: pipelines:  default:    - step:        name: Build & Test        script:          - echo "Running build"          - mvn clean install Push code → Pipeline triggers automatically. 🔹 9️⃣ Best Practice (Jira Integration) Always include Jira ticket key in: Branch name → feature/PROJ-101-description Commit message → PROJ-101 fixed issue This auto-links to Jira. 🔥 Real DevOps Workflow 1️⃣ Create branch 2️⃣ Commit changes 3️⃣ Push to Bitbucket 4️⃣ Create Pull Request 5️⃣ Pipeline runs 6️⃣ Merge after approval 7️⃣ Deploy 🎯 Most Used Daily Commands ✔ git clone ✔ git checkout -b ✔ git add ✔ git commit ✔ git push ✔ git pull ✔ git merge ✔ git rebase #Bitbucket #Git #DevOps #CICD #Atlassian #VersionControl #Automation #SoftwareDevelopment #CloudEngineering #TechCareers

🚀 Jenkins CI Workflow Explained: From Code Push to Automated Build In modern DevOps, automation is everything. One of the most common questions is: 👉 “What happens after a developer pushes code to GitHub? How does Jenkins pick it up and trigger a build?” Let’s break this down in a simple, practical way 👇 🔄 End-to-End CI Workflow (Jenkins + GitHub) 🧑💻 Step 1: Developer Pushes Code A developer writes code and pushes it to a GitHub repository: git add . git commit -m "New feature" git push origin main ⚙️ Step 2: CI Server (Jenkins) Picks Up Changes Jenkins acts as the CI Server, which can be: 🌐 Public (accessible over internet) 🔒 Private (inside organization network) Now the key question: 👉 How does Jenkins know code has changed? This is where triggers come into play 👇 🔔 Jenkins Build Trigger Mechanisms 1️⃣ Webhooks (Real-Time Trigger) 🚀 ✅ How it works: GitHub sends an HTTP POST request to Jenkins immediately after a push Jenkins receives the signal and starts the build instantly 🔄 Flow: Developer Push → GitHub → Webhook → Jenkins → Build Triggered ⚡ Key Features: Real-time execution (no delay) Independent of time Most efficient and recommended approach 🛠️ Setup Steps: Go to GitHub repo → Settings → Webhooks Add: Payload URL: http://<jenkins-url>/github-webhook/ In Jenkins: Enable: “GitHub hook trigger” 📌 Use Case: Fast feedback CI/CD pipelines Production-grade DevOps setups 2️⃣ Poll SCM (Polling-Based Trigger) ⏱️ ✅ How it works: Jenkins checks GitHub repo at regular intervals If changes are detected → triggers build 🔄 Flow: Jenkins Scheduler → Checks Repo → Changes Found → Build Triggered ⏰ Example Cron: */5 * * * * 👉 Checks every 5 minutes ⚡ Key Features: Depends on time + commits Slight delay compared to webhooks No GitHub configuration needed 📌 Use Case: When webhook setup is restricted Internal/private repositories 3️⃣ Build Periodically (Time-Based Trigger) 🕒 ✅ How it works: Jenkins triggers build at fixed intervals Does NOT depend on code changes 🔄 Flow: Scheduler Time → Jenkins → Build Triggered (even without changes) ⏰ Example Cron: 0 0 * * * 👉 Runs daily at midnight ⚡ Key Features: Independent of commits Purely time-driven Useful for scheduled jobs 📌 Use Case: Nightly builds Backup jobs Health checks Complete CI Flow (Real World) 1. Developer pushes code to GitHub 2. GitHub sends webhook (or Jenkins polls repo) 3. Jenkins triggers pipeline 4. Code is cloned into Jenkins workspace 5. Build process starts: - Compile code - Run tests - Build Docker image (optional) 6. Artifacts are generated 7. Deployment step (CD) may follow ✅ Always prefer Webhooks for real-time CI ⚠️ Use Poll SCM only if webhook is not possible 🕒 Use Build Periodically for scheduled operations 📢 Final Thought A well-configured Jenkins pipeline transforms your development process from manual → automated → scalable.

Git Commands Every DevOps Engineer Should Know In my experience working with development and deployment workflows, understanding Git (Version Control System / SCM) is essential. It helps track changes, collaborate with teams, and manage code efficiently in real-world environments. Here’s a simple and practical breakdown of Git basics and commonly used commands 👇 📌 What is Git? Git is a distributed version control system that helps you: ✔️ Track code changes ✔️ Collaborate with teams ✔️ Maintain version history ✔️ Roll back when things go wrong 📌 Git Workflow (Stages) 1️⃣ Working Directory Where you create and modify files 2️⃣ Staging Area (Index) Where you prepare changes before committing 3️⃣ Repository (.git) Where Git permanently stores your commits 📌 Installing Git 👉 yum install git -y yum → Package manager install git → Installs Git -y → Automatically says “yes” to prompts 📌 Basic Git Commands 👉 git -v Shows Git version installed 👉 git init Initializes a new Git repository 👉 git status Shows current state (tracked/untracked files) 👉 git log Displays commit history 👉 git show Shows detailed info about a commit 👉 git add <file> Adds file to staging area 👉 git commit -m "message" Saves changes to repository with a message 👉 git rm --cached <filename> Removes file from Git tracking (keeps file locally) 📌 Difference: git add . vs git add * ✔️ git add . Adds all files (including hidden files & folders) ✔️ git add * Adds only visible files (not hidden ones like .gitignore) 👉 In real-world usage, git add . is preferred 📌 Git Configuration 👉 git config --global user.name "Your Name" 👉 git config --global user.email "your@email.com" Sets your identity for commits 📌 Amend Command 👉 git commit --amend Modify last commit (message or files) Useful when you forgot something in previous commit 📌 Ignoring Files (.gitignore) Create a .gitignore file and add: *.log node_modules/ .env 👉 Prevents unwanted files from being tracked 📌 Undo Changes (Reset) 👉 git reset Unstages files (moves from staging → working directory) 👉 git reset --hard Deletes all changes 📌 Cherry Pick (Advanced & Useful) 👉 git cherry-pick <commit_id> Applies a specific commit from another branch 💡 Very useful when you need only one fix, not the whole branch 💡 These Git commands are part of my daily workflow for: ✔️ Code versioning ✔️ Debugging issues ✔️ Managing deployments ✔️ Collaborating with teams I’ve compiled this as part of my continuous learning and hands-on practice in DevOps. Let’s keep learning and growing 🚀 #DevOps #Git #Linux #Cloud #Automation #VersionControl

Day 2 of #30DaysOfDevOps — Git & GitHub Basics Every DevOps engineer lives inside Git. If you don't understand how Git works, collaboration and CI/CD pipelines become a nightmare. Let's break it down. 1. What is Version Control? Version control tracks every change made to your codebase over time. Think of it as an unlimited undo button for your entire project — roll back anything, see who changed what, and work on multiple features in parallel. 2. Why Git? Git is distributed — every developer has a full copy of the repo locally. No internet? You can still commit, branch, and diff. It's the industry standard that every CI/CD tool integrates with natively. 3. The Three States of Git Working Directory — where you edit files Staging Area — where you prepare changes before committing Commit History — permanent snapshots of your project git add index.html git commit -m "Add landing page structure" 4. Essential Git Commands git init — create a new local repository git status — see what's changed and what's staged git add . — stage all modified files git commit -m "msg" — save a snapshot git log --oneline — view a clean commit history git diff — see exactly what changed before staging 5. Branching & Merging Branches let you work in isolation without touching the main codebase. git checkout -b feature/user-auth git checkout main git merge feature/user-auth 6. Connecting to GitHub git remote add origin https://lnkd.in/gQZps_k7 git branch -M main git push -u origin main 7. Resolving Merge Conflicts Conflicts happen when two branches edit the same lines. Git marks them: <<<<<<< feature/user-auth const port = 4000 ======= const port = 3000 >>>>>>> main Open the file, pick the correct version, remove the markers, then: git add app.js git commit 8. Challenges for Today 1. Configure your Git username and email globally. 2. Create a folder, initialize a repo, add files, and make your first commit. 3. Create a branch called feature-branch, make a change, and commit it. 4. Merge the feature branch into main and push to GitHub. Try them out and share what you build. Post 2 drops later today — Git Advanced: Rebase, Cherry-pick & Conflict Resolution. #DevOps #Git #GitHub #VersionControl #30DaysOfDevOps #LearningInPublic #DevOpsEngineer #CloudComputing

🚀 GIT: 🔹 What is Git? Git is a distributed version control system used to track changes in files and source code. It helps developers manage project history, collaborate with teams, and maintain multiple versions of the same project efficiently. Git was created in 2005, is open-source, platform-independent, and is widely used in modern software development. 🔹 Why do we use Git? The main purpose of Git is to: - Track changes in files over time - Maintain different versions of the same project - Collaborate with multiple team members - Restore previous versions when needed - Manage project history in an organized way In simple words, Git helps us save, track, and manage code changes safely. 🔹 Basic Git Workflow Git mainly works in 3 stages: 1️⃣ Working Directory This is the current project folder where we create or modify files. 2️⃣ Staging Area This is the intermediate area where we place the files that we want to include in the next commit. 3️⃣ Repository This is where Git permanently stores the committed changes and project history. 👉 Flow: Working Directory → Staging Area → Repository --- 🔹 Basic Git Commands : ✅ Install Git yum install git -y ✅ Check Git Version git --version ✅ Initialize a Git Repository git init ✅ Create a File touch aws ✅ Track a File git add aws ✅ Track All Files git add . ✅ Check Status git status ✅ Commit Changes git commit -m "Added aws file" file name --- 🔹 Git Configuration Before making commits, we can configure our Git username and email: > git config --global user.name "Your Name" >git config --global user.email "yourmail@example.com" These details are attached to every commit and help identify the author of changes. --- 🔹 Useful Git History Commands 1.View commit history >git log 2.View commit history in one line >git log --oneline 3.View latest 2 commits >git log -2 4.Show commit details >git show <commit-id> --- 🔹 Types of Repositories - Local Repository → Exists in our local system inside the ".git" folder - Remote Repository → Hosted on platforms like GitHub, GitLab, or Bitbucket --- Git is not just a tool for developers — it is a must-have skill for DevOps engineers as well. It helps in: - Source code management - Collaboration - Change tracking - Deployment workflows - CI/CD integration