Git & GitHub Basics for DevOps Engineers

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

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

Working with Git feels smooth… until this happens: 👉 You try to push 👉 Git says “rejected” 👉 You open the file… and see <<<<<<< HEAD Welcome to merge conflicts 😄 And then there’s another silent problem: 👉 Your repo slowly fills up with files that shouldn’t even be there That’s where .gitignore comes in. This blog breaks down both of these in a simple, practical way so you know exactly what’s happening and what to do next. Here’s what this Blog/Attached Dcument covers: 1) What actually causes a merge conflict 2) How conflicts happen in real team scenarios 3) Why Git blocks your push (and why that’s a good thing) 4) What git pull --rebase does during conflicts 5) How to read conflict markers inside a file 6) The 3 ways to resolve a conflict (keep theirs, yours, or both) 7) How to continue after fixing conflicts 8) Using git status as your guide 9) What .gitignore is (and why it’s essential) 10) What files should never go into Git 11) How to create and use a .gitignore file 12) Why .gitignore doesn’t affect already tracked files 13) How to fix that using git rm --cached 14) A clean workflow to fix and maintain your repo One key idea: A merge conflict is not an error. It’s Git saying: 👉 “I found two valid versions… you decide the final one.” Think of it like two people editing the same sentence differently. Git shows both. You pick (or combine) the correct version. And .gitignore? It’s simply your way of telling Git: 👉 “Track the important stuff. Ignore the noise.” This blog helps you move from confusion → clarity when working with real Git workflows. You can read the complete blog using the link below, or you can review the attached document—both contain the same information: https://lnkd.in/gEySNV4i Quick takeaway: Understand conflicts + use .gitignore properly = cleaner code, cleaner repo, fewer headaches. Comment what should I write about next? Feel free to comment below & I’ll try to create a post on your suggestion within a day. I can cover topics like: Git, Ansible, Jenkins, Groovy, Terraform, AWS, Networking, Linux, DevOps practices, Cloud architecture, CI/CD pipelines, Infrastructure as Code, or anything related. If you find the content useful, please share it with your network and drop a like 👍 it really helps these posts reach more Linux, DevOps, and Cloud folks. Your likes and shares are what keep me motivated to keep writing consistently. Thanks in advance for your ideas and support! #Git #VersionControl #DevOps #Linux #SoftwareDevelopment #GitRebase #Gitignore #LearningJourney #TechCareers

⚡ From git init to GitOps — The Only Git + DevOps Cheat Sheet You’ll Ever Need Most developers know git add and git commit. Very few understand what happens when things break in production. This PDF is not just a Git command list. It’s a complete Git + DevOps practical guide from basics to advanced workflows used in CI/CD, Docker, Kubernetes, and GitOps environments. If you want to move from “I use Git” to “I understand version control deeply”, this is for you. 📌 What’s inside this PDF? 🔹 Core Git Foundations Init, Clone, Add, Commit, Push, Pull Branching & Merging Staging & Reset strategies Viewing logs, diffs & commit history 🔹 Advanced Git Concepts Rebase & Interactive Rebase Cherry-pick, Bisect (bug tracking) Merge conflict strategies Reflog & history recovery Submodules & Subtrees 🔹 Power User Features Git Hooks (pre-commit, post-merge, pre-push) Aliases & Config optimization Commit signing (GPG) Clean, prune & garbage collection 🔹 Git for DevOps & CI/CD Git in CI/CD pipelines GitOps workflow Version tagging & release management Infrastructure as Code (IaC) Multi-environment deployments Docker & Kubernetes integration Rollbacks & deployment automation 💡 Why this matters In real-world engineering: Git mistakes break production Bad merges create chaos Poor branching strategy slows teams Understanding Git deeply = ✔️ Cleaner history ✔️ Safer deployments ✔️ Better collaboration ✔️ Strong DevOps credibility 📈 How to use this PDF Start with core commands Move into rebase & conflict resolution Practice rollback scenarios Study GitOps & CI/CD sections if targeting DevOps roles 🎯 Perfect for: ✔️ Backend Developers ✔️ DevOps Engineers ✔️ SDE aspirants ✔️ Engineering students ✔️ Anyone working in collaborative projects 📌 Save this — Git knowledge compounds over time 👥 Share with someone who still uses git push --force blindly Master Git once. Avoid production disasters forever. Follow SphereX for more!! LinkedIn LinkedIn for Marketing LinkedIn Talent Solutions LinkedIn News LinkedIn News India Get Hired by LinkedIn News Asia Mohit Jaryal Aniket Singh #SphereX #Git #GitHub #VersionControl #DevOps #CICD #SoftwareEngineering #BackendDeveloper #CloudComputing #Docker #Kubernetes #GitOps #InfrastructureAsCode #Programming #CodingLife #TechCareers #DeveloperCommunity #EngineeringStudents #SDE #BuildInPublic #OpenSource #Automation #ContinuousIntegration #ContinuousDelivery #TechSkills

🛠 **Top 10 Git Commands Every Developer & DevOps Engineer Should Master in 2026** Whether you're a beginner or a seasoned pro, these 10 Git commands are used daily in real-world projects. Save this post — it’s your quick Git cheat sheet! ### 1. `git clone <repository-url>` **Use:** Downloads a complete copy of a remote repository to your local machine. The first command you run when starting work on any project. ### 2. `git status` **Use:** Shows the current state of your working directory — which files are modified, staged, or untracked. Your best friend for avoiding mistakes. ### 3. `git add <file>` or `git add .` **Use:** Stages changes (modified or new files) to be committed. Use `.` to stage everything. ### 4. `git commit -m "Your meaningful message"` **Use:** Records your staged changes with a clear description. Good commit messages = better team collaboration. ### 5. `git push origin <branch-name>` **Use:** Uploads your local commits to the remote repository (usually GitHub/GitLab). Example: `git push origin main` ### 6. `git pull` **Use:** Fetches latest changes from the remote repository and merges them into your current branch. Run this often to stay in sync with the team. ### 7. `git branch` / `git branch <new-branch-name>` **Use:** Lists all branches or creates a new branch. Essential for feature development and bug fixes. ### 8. `git checkout <branch-name>` or `git switch <branch-name>` **Use:** Switches to another branch. `git switch` is the modern, safer alternative. ### 9. `git merge <branch-name>` **Use:** Merges changes from another branch into your current branch. Commonly used to bring feature branches into main. ### 10. `git log` **Use:** Displays the commit history of the current branch. Add `--oneline` for a clean, compact view: `git log --oneline` --- **Bonus Tip:** Combine commands for speed: `git add . && git commit -m "fix: login bug" && git push` Which Git command do you use the most? Or which one do you still find confusing? Drop it in the comments 👇 Let’s help each other! #Git #GitCommands #DevOps #DeveloperTips #VersionControl #SoftwareEngineering

In real-world development, work rarely happens in a straight line. You start working on something… then suddenly need to switch branches, debug another issue, or check something in the main codebase. That’s where many people get stuck with Git. This blog focuses on two concepts that act as safety nets when your workflow gets interrupted: Git Stash and Git History. It explains both in a simple and practical way so you can handle interruptions and explore past code without confusion. Here’s what this Blog/Attached PDF covers: 1) The problem Git stash is designed to solve 2) What git stash actually does 3) Why Git blocks branch switching with uncommitted changes 4) How to stash your work safely 5) Switching branches and returning without losing changes 6) Restoring changes using git stash pop 7) Using stash within the same branch for debugging 8) Why stash should be used only as a temporary tool 9) What commit hashes are and why they matter 10) How to read commit history using git log 11) Checking out specific commits from the past 12) Understanding detached HEAD state 13) Practical use cases like debugging and verification 14) How to return to the latest state of your code One key idea: Git stash lets you temporarily set aside your work so you can switch context without committing incomplete changes. Git history lets you move through different points in your project’s timeline and understand how things evolved. Together, they give you control over both your present work and your past changes. This blog helps you build that confidence so you can work more freely without worrying about losing progress or getting stuck. You can read the complete blog using the link below, or you can review the attached document—both contain the same information: https://lnkd.in/gJeRKiPm Quick takeaway: Understanding stash and history makes it much easier to handle interruptions, debug issues, and explore your code safely. Comment what should I write about next? Feel free to comment below & I’ll try to create a post on your suggestion within a day. I can cover topics like: Git, Ansible, Jenkins, Groovy, Terraform, AWS, Networking, Linux, DevOps practices, Cloud architecture, CI/CD pipelines, Infrastructure as Code, or anything related. If you find the content useful, please share it with your network and drop a like, it really helps these posts reach more Linux, DevOps, and Cloud professionals. Your support helps me continue creating consistent content. Thanks in advance for your ideas and feedback. #Git #VersionControl #DevOps #Linux #SoftwareDevelopment #GitStash #LearningJourney #TechCareers

Part-1: 🚀 Git Roadmap: From Fresher to Intermediate (Step-by-Step Guide) Git is not just a tool — it’s a must-have skill for every developer & DevOps engineer. If you're starting your journey or struggling with Git concepts, this roadmap will help you learn Git in a structured and easy way 👇 🟢 1. Getting Started What is Git & why it matters Install Git Configure your identity git config --global user.name "Your Name" git config --global user.email "your@email.com" 🔵 2. Basic Workflow (Core Commands) git init → Initialize repo git status → Check changes git add . → Stage changes git commit -m "message" → Save changes git log → View history 👉 Master this section — it's used daily! 🟡 3. Branching & Merging git branch → Create/list branches git checkout -b feature → New branch git switch → Move branches git merge → Combine branches 💡 This is where real teamwork starts! 🟣 4. Remote Repositories GitHub / GitLab / Bitbucket git remote add origin <url> git push -u origin main git pull 🤝 Learn collaboration & PR workflow 🔴 5. Undoing Changes git checkout -- file git reset (soft/mixed/hard) git revert ⚠️ Important: Know when to use what! 🟠 6. Intermediate Concepts .gitignore → Ignore files git stash → Save temporary work Rebase vs Merge Interactive rebase Clean commit history ⭐ Best Practices ✔ Write meaningful commit messages ✔ Commit small & frequently ✔ Always pull before push ✔ Use branches for features ✔ Review before merging 🎯 Goal Become confident with Git, collaborate smoothly, and never lose your code again 💪 📌 Tip: Don’t just read — practice daily on real projects! 💾 Save this post for later & follow for more DevOps content. #Git #DevOps #VersionControl #Developer #LearnInPublic #TechRoadmap #Cloud #Programming

🛠️ I built a tool that I wish existed when I was learning Git the hard way. The Problem: Most Git tutorials teach you git add, git commit, git push — and stop there. But in real production environments, that's where the easy part ends. I've seen engineers freeze when they accidentally commit AWS credentials to main. I've seen teams spend hours untangling a botched rebase on a release branch. I've seen 2AM hotfixes go wrong because no one had actually practiced that workflow before the incident happened. Reading about git reflog or git cherry-pick is not the same as doing it under pressure. And there was no tool that let you practice the hard stuff in a safe, realistic environment — without setting up a repo, a server, or anything at all. The Solution: I built GitPath — a fully browser-based, interactive Git learning platform designed around real production scenarios. It's built around the situations that actually matter on the job: 🔥 2AM hotfix on a live production system  🔐 AWS credentials accidentally pushed to main — revert, rotate, document  🚢 Full GitFlow release cycle from feature branch to tagged deployment  🧲 Recovering lost commits using git reflog  ⚔️ Resolving a merge conflict between two engineers on the same file Beyond scenarios, it covers 7 structured learning tracks and 28 guided lessons — from absolute basics all the way to Conventional Commits, Monorepo Git strategy, and Branch Protection rules used in enterprise CI/CD pipelines. Every lesson has a real-world story behind it, not just dry command documentation. How Easy Is It to Use: This is the part I'm most proud of. There is nothing to install. No npm. No server. No account. No configuration. You open one HTML file in your browser and you're inside a live Git terminal with a visual branch graph that updates in real time as you type commands. Your progress, XP, and streak are saved automatically in your browser. You can pick it up, put it down, and come back exactly where you left off. If you get stuck, there's a built-in hint system. If you want to explore freely, there's an open sandbox playground with no objectives at all. One file. Any browser. Zero friction. Built this as part of my DevOps portfolio — and it reflects the git workflows I rely on every day working on production AWS environments. 🔗 Try it in 10 seconds — no signup needed: https://lnkd.in/gVWKzBKd 🐙 GitHub: https://lnkd.in/gSD3SY_w If you're a DevOps, Platform, or SRE engineer — I'd genuinely love to hear what scenarios you'd add. Drop a comment or connect. #DevOps #Git #AWS #OpenSource #LearningInPublic #DevSecOps #SRE #PlatformEngineering #CloudEngineering #GitFlow

🚀 Stop Merging Everything — Smart Engineers Use git cherry-pick 🍒 | GitHub for DevOps Day 5 (Final Part) In fast-paced DevOps environments, not every change needs a full merge. Sometimes, you only need one specific fix — not the entire branch. That’s where git cherry-pick becomes a powerful tool. 🔹 What is git cherry-pick? git cherry-pick allows you to take a specific commit from one branch and apply it to another branch — without merging everything. 👉 Think of it like picking one cherry 🍒 from a tree, not the whole tree. 🧠 Simple Visualization main: A → B → C feature: D → E 👉 Need only commit D? git cherry-pick <commit-id> ✅ Result: main: A → B → C → D 🧪 Practical Workflow 1️⃣ Check commits git log --oneline 2️⃣ Switch to target branch git checkout main 3️⃣ Apply specific commit git cherry-pick <commit-id> 4️⃣ Verify git log --oneline 🔥 Where is it used? ✔ Bug fixes in production ✔ Hotfixes across multiple branches ✔ Selective feature transfer ✔ Avoiding unnecessary merges ⚡ When should you use it? ✅ You need only one fix, not full feature changes ✅ You want to avoid merge conflicts from unrelated commits ✅ Same fix must be applied to multiple branches (main, staging, etc.) ⚠️ Handling Conflicts If conflicts occur: git add . git cherry-pick --continue 💡 Pro Tip Always verify commit ID before applying: git log --oneline 🔁 Quick Recall ✔ git cherry-pick → copy one commit 🍒 ✔ git fetch → download changes without applying 📥 🚀 Final Takeaway In real-world DevOps workflows, precision matters. 👉 Don’t move entire branches when one commit is enough. #HiteshDevOps #DevOps #Git #GitHub #CI_CD #Docker #Kubernetes #AWS #OpenToWork #HiringDevOps #DevOpsEngineer #TechHiring #LearningInPublic #BuildInPublic #TechJourney

🏆 Day 10/10: THE GRAND FINALE! Building an End-to-End CI/CD Pipeline in Jenkins! 🚀🏭 Post Content: Hello Connections! 👋 Welcome to the GRAND FINALE of our 10-Day Jenkins Challenge! 🎉 Over the past 9 days, we learned the individual pieces of the puzzle: Architecture, Pipelines as Code, Webhooks, Quality Gates, Credentials, and Parallel Execution. Today, we put it all together. We are building the Ultimate Enterprise Factory! 🏭 🌍 The Real-World End-to-End Workflow: When a developer types git push today, here is the exact journey their code takes in a modern DevOps company: 1️⃣ The Trigger: GitHub fires a Webhook to Jenkins. 2️⃣ The Allocation: The Jenkins Master assigns the job to a secure Linux Docker Agent. 3️⃣ The Checkout: Jenkins securely pulls the latest code. 4️⃣ The Build: Maven/npm compiles the code into an Artifact. 5️⃣ The Quality Gate: The code is scanned by SonarQube for vulnerabilities. (If it fails, the pipeline dies here 🛑). 6️⃣ The Containerization: Jenkins builds a Docker Image and securely pushes it to AWS ECR / DockerHub using masked credentials. 7️⃣ The Deployment: Jenkins updates the Kubernetes cluster with the new image for a Zero-Downtime rollout. 8️⃣ The Feedback: Jenkins sends a beautiful success/failure notification directly to the team's Slack channel! 🔔 🐱🐭 The Tom & Jerry Analogy (The Perfect Factory): --> Day 1 (Jerry): Running around manually testing and carrying heavy servers. Exhausted and prone to errors. --> Day 10 (Tom & Jerry together): They press ONE button. A highly sophisticated, laser-guided conveyor belt automatically builds, tastes, packages, and delivers the perfect cheese pizza to the customer while they sit back and play video games! 🍕🎮 🔥 The Cultural Shift (DevSecOps): CI/CD is not just a tool; it's a culture. By automating testing and security (DevSecOps), we don't just deploy faster—we deploy safer. 👇 Today's Final Challenge: We made it! 🎊 Thank you to everyone who followed this 10-day journey. What was your biggest learning moment from this Jenkins series? Let’s celebrate in the comments! 👇 blog link: update soon... #Jenkins #DevOps #CICD #Day10 #10DayChallenge #GrandFinale #Automation #SoftwareEngineering #Kubernetes #Docker #TechCommunity