Git Remote Repositories: origin, push, pull, and fetch explained

🚨 DevOps Error: Git Push Rejected – non-fast-forward. While pushing code to the remote repository, Git returned this error: ! [rejected] main -> main (non-fast-forward) error: failed to push some refs to origin At first it looked like a permission issue, but the real problem was different. 🔍 Debugging: * I checked the repository and realized that someone else had already pushed new commits to the same branch. * My local branch was behind the remote branch. ✅ Solution: First I pulled the latest changes: * git pull origin main After resolving the merge updates, I pushed again: * git push origin main This time the push worked successfully. 💡 Lesson Learned: When working in teams, always pull the latest changes before pushing to avoid conflicts. DevOps is not only about infrastructure and pipelines — version control practices matter just as much. #DevOps #Git #VersionControl #CloudEngineering #LearningInPublic

Day 26–27 | From Version Control to Professional Identity Over the last two days, I shifted focus from writing code to improving how I operate and present myself as a DevOps engineer. 🔹 Day 26 – GitHub CLI (gh) I learned how to manage repositories, issues, pull requests, and workflow runs directly from the terminal using GitHub CLI. Key takeaways: ▪️ Created and merged PRs without leaving the terminal ▪️ Managed issues programmatically ▪️ Explored GitHub Actions workflow monitoring via CLI ▪️ Understood how gh enables automation and scripting at scale This reinforced an important principle: real DevOps efficiency comes from minimizing context switching and maximizing automation. 🔹 Day 27 – GitHub Profile Makeover Today was about professional branding and visibility. Actions taken: ▪️ Created a structured GitHub profile README ▪️ Organized repositories (90 Days of DevOps, shell-scripts, python-scripts, devops-notes) ▪️ Cleaned up unused/irrelevant repos ▪️ Improved documentation and naming consistency ▪️ Pinned repositories that best represent my technical direction Key realization: Your GitHub profile is not just a code archive — it’s your technical portfolio. As I continue the 90 Days of DevOps journey, I’m focusing not only on learning tools but also on building a professional engineering identity. 📂GitHub CLI (gh) : 👉https://lnkd.in/gtHtu4Mv 📂GitHub Profile Makeover : 👉https://lnkd.in/griN2cYu #DevOps #GitHub #Automation #GitHubCLI #PersonalBranding #ContinuousLearning #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham Happy Learning! TrainWithShubham

Automated Node.js Application Deployment using Jenkins CI/CD Workflow I’m excited to share my latest DevOps project where I built a fully automated CI/CD pipeline for a Node.js application using Jenkins, GitHub, and PM2! - Set up CI/CD infrastructure - Configured Jenkins Master & Target Server - Enabled GitHub Webhooks for automated deployment - Deployed Node.js app with zero manual steps This setup ensures that every push to GitHub automatically deploys the latest version of the app to an Ubuntu server — making deployments seamless, reliable and production-ready! Highlights: - Automated build + deployment - SSH-based secure connection - PM2 process manager - Fast rollback and monitoring - Real-world DevOps workflow 🔗 Explore the full code and detailed setup guide here: https://lnkd.in/ds9NxNP5 Read the full article on Medium (step-by-step explanation): https://lnkd.in/drHztSmd #devops #jenkins #cicd #nodejs #automation #github #cloudcomputing #softwareengineering #continuousdeployment

💻 Git Workflow: Essential Commands Every Developer Should Know Git has dozens of commands, but in daily development most workflows rely on a small core set. The real challenge is not remembering commands. It is understanding where your code moves after each command. In Git, your code typically moves between four places: • Working Directory → your local files • Staging Area → files prepared for commit • Local Repository → saved commits on your machine • Remote Repository → shared code (GitHub, GitLab, Azure DevOps) Once you understand this flow, Git becomes much easier. 📦 Saving Your Work git add Moves changes from the working directory → staging area git commit Saves staged changes into the local repository git push Uploads your commits from local repository → remote repository 📥 Getting a Project git clone Downloads the entire remote repository to your machine. git checkout Switches to a specific branch or commit. 🔄 Syncing Changes git fetch Downloads updates from the remote repository without modifying your working files. git merge Combines fetched changes with your current branch. git pull A shortcut for: git fetch + git merge 🧰 The Safety Net git stash Temporarily saves uncommitted changes so you can switch branches without losing work. git stash apply Restores the saved changes. git stash pop Restores the changes and removes them from stash. 💡 Key Insight Git commands are simple once you understand how code flows between the working directory, staging area, and repositories. Most Git mistakes happen when developers run commands without knowing where their changes are stored. Master these few commands, and you can handle most real-world Git workflows confidently. #Git #SoftwareDevelopment #Programming #Developers #VersionControl #Coding PC: Alex Xu

Day 33 of 100 Days of DevOps with KodeKloud 🚀 Resolve Git Merge Conflicts Today I focused on one of the most practical and unavoidable parts of collaborative development resolving merge conflicts. Conflicts happen when multiple changes affect the same lines of code. They are not failures they are part of teamwork. Today I practiced: 🔹 Simulating a merge conflict between branches 🔹 Understanding conflict markers (<<<<<<<, =======, >>>>>>>) 🔹 Manually editing and resolving conflicting code 🔹 Staging resolved files 🔹 Completing the merge process 🔹 Testing after resolving conflicts Key Concept: Conflict → Analyze changes → Decide correct version → Edit manually → Add & Commit → Continue workflow In real DevOps environments: Multiple Developers → Modify same file → Merge Attempt → Conflict Appears → Resolution → CI/CD Pipeline Runs Conflict resolution requires: • Clear understanding of code changes • Communication between team members • Careful review before merging This is where engineering discipline matters most. Merge conflicts are not about Git They are about collaboration. Understanding how to confidently resolve conflicts is a core DevOps skill. 33 days in. From writing commits → to managing real collaboration challenges. #100DaysOfDevOps #Git #DevOpsJourney #MergeConflicts #CI_CD #Linux #Automation #FutureDevOpsEngineer

🚀 Git vs GitHub vs GitLab — Stop Confusing Them! Many developers use these terms interchangeably, but they are not the same. If you're starting in software development, understanding the difference is important. Let’s simplify it 👇 🔹 Git Git is a version control system. It helps developers track code changes, collaborate with teams, and manage different versions of a project. Think of Git as the engine that tracks your code history. Example commands: • git init • git commit • git push • git pull 🔹 GitHub GitHub is a cloud platform that hosts Git repositories. It allows developers to: • Store code online • Collaborate using pull requests • Manage issues • Review code • Build open-source projects Think of GitHub as a social network + storage for Git projects. 🔹 GitLab GitLab is another Git repository hosting platform, similar to GitHub but with built-in DevOps features. It includes: • CI/CD pipelines • Security scanning • Project management • Full DevOps lifecycle tools Think of GitLab as Git hosting + complete #DevOps platform. 📌 Quick Analogy Git = The version control tool GitHub = A place to store and collaborate on Git projects GitLab = Git hosting + DevOps automation 💡 As developers, we don’t just write code anymore. We manage version control, collaboration, #CI/CD, and #deployment pipelines. Understanding these tools is the first step toward professional software development. 💬 Question for developers: Do you prefer GitHub or GitLab for your projects? And why? #Git #GitHub #GitLab #SoftwareDevelopment #Programming #Developers #DevOps #TechCareer

GIT CONFUSION is costing you hours. Most developers use Git daily But very few actually understand What’s happening under the hood. That’s why you see: Accidental commits to the wrong branch Messed up merges Panic after git reset --hard Fear of rebasing Here’s the simple mental model most people miss Git has 4 core areas: 1. Working Directory – The files you’re actively editing. 2. Staging Area (Index) – The snapshot you’re preparing for commit. 3. Local Repository (.git) – Where commits are stored locally. 4. Remote Repository (GitHub/GitLab/Bitbucket) - Shared version of your repo. Now map commands to movement: git add → Working Directory ➝ Staging git commit → Staging ➝ Local Repository git push → Local ➝ Remote git pull / git fetch → Remote ➝ Local git checkout → Switch branches / restore files git reset → Rewind staging or commit history When you understand this flow Git stops being “magic” and starts being predictable. Power tip If something breaks, ask: “Which layer am I in?” That single question prevents 80% of Git mistakes. If you had to explain Git in one sentence to a junior dev What would you say? Follow Emmanuel Alafonye, M.Eng for more DevOps, Cloud and AI Content.

Stop just "saving" code. Start mastering it. Whether you're a developer, a DevOps engineer, or a tech enthusiast, understanding Git and GitHub isn't just a skill—it’s the "Single Source of Truth" for modern software delivery. I’ve been diving deep into Version Control Systems (VCS) recently, and I wanted to break down the core concepts that every tech professional should have in their toolkit. Centralized vs. Distributed (CVCS vs. DVCS) Old school (SVN/Perforce) relied on one central server. If it went down, work stopped. 🛑 Modern school (Git/Mercurial) is distributed. Every developer has the full history. If the server dies, the code lives on your machine. 🛡️ Git vs. GitHub: What's the difference? Git: The engine under the hood. It’s the local software that tracks your changes. GitHub: The social club for code. It’s the cloud platform where we collaborate, review PRs, and run CI/CD pipelines. The 3 States of Git (Your Workflow Path) Understanding how code moves is key to avoiding merge nightmares: 🔹 Working Directory: Where you write and modify files. 🔹 Staging Area: The "prep zone" where you pick what changes to include. 🔹 Git Directory: The final snapshot where history is permanently recorded. Pro-Tips for the DevOps Workflow: Branching: Work in isolation (feature-login, hotfix-patch) to keep production safe. 🌿 .gitignore: Always hide your secrets! Keep node_modules and .env files out of your repo. 🔒 Forking: The ultimate way to contribute to Open Source. Copy, modify, and propose changes via Pull Request. Version control is the foundation of automation, quality, and high-velocity delivery. If you aren't using Git, you aren't doing DevOps! What’s one Git command you can’t live without? Let’s chat in the comments! 👇 #DevOps #Git #GitHub #VersionControl #SoftwareEngineering #TechLearning #CloudComputing #OpenSource #SoftwareDevelopment #CareerGrowth#DevOps

Git Pull vs Git Fetch: - If you’re working in a team environment, understanding the difference between git pull and git fetch can save you from messy merges and broken builds. Here’s the simple breakdown: 1. git fetch: Downloads new commits from remote Updates remote tracking branches Does NOT change your current branch Safe for reviewing before merging Best for controlled workflows and production environments. 2. git pull = git fetch + merge (or rebase) Updates your current branch immediately Can create unexpected merge commits Best when you just want to quickly sync changes. In CI/CD workflows, many teams prefer: git fetch git diff origin/main git merge origin/main Why? Because visibility before integration = fewer surprises in pipelines. If you're serious about mastering Git workflows as a Developer or DevOps Engineer, this is foundational knowledge. Full practical guide with real examples here: https://lnkd.in/gAuu5f7N

🚀 GitHub vs GitLab – What’s the Real Difference? As developers, we often hear GitHub and GitLab used interchangeably. Both are powerful platforms built around Git — but they solve problems in slightly different ways. Let’s break it down 👇 🔹 GitHub What problem it solves: ✔ Centralized code hosting ✔ Collaboration for distributed teams ✔ Version control & change tracking ✔ Open-source community management Advantages: ✅ Massive developer community ✅ Best platform for open-source projects ✅ Strong ecosystem (Actions, Marketplace) ✅ Owned by Microsoft – strong enterprise support ✅ Clean, beginner-friendly UI GitHub is often the first choice for startups, open-source contributors, and developers building public portfolios. 🔹 GitLab What problem it solves: ✔ Complete DevOps lifecycle in one platform ✔ Built-in CI/CD ✔ Integrated security & monitoring ✔ Self-hosted DevOps control Advantages: ✅ All-in-one DevOps solution ✅ Strong CI/CD pipeline (built-in) ✅ Better for private repositories (free tier) ✅ Easier self-hosted setup ✅ Strong DevSecOps focus GitLab is ideal for teams that want everything — code, CI/CD, security, and deployment — in one place. 🆚 Quick Comparison 👉 GitHub = Collaboration + Community 👉 GitLab = Complete DevOps Platform Both are powerful. The right choice depends on your team size, project type, and DevOps needs. 💬 Which one do you prefer and why? #GitHub #GitLab #DevOps #SoftwareDevelopment #Programming #Developers #TechCareer