Git Commands for DevOps Engineers and AI Developers

Today I learned: Merge & Rebase, Stash, Cherry- picking, Squash commit, Merge commit, Revert, Reset, and Branching Strategies. Merge: (Merge two branches) git merge <branch-name> git branch -d <branch-name> Rebase: (Create a single linear history) git rebase <branch-name> Stash: (Temporarily save uncommitted changes) git stash git stash push -m "message" git stash list git stash apply git stash pop git stash pop stash@{1} git stash drop git stash drop stash@{1} git stash clear Cherry-picking: (Pick a specific commit and apply it to another branch) git cherry-pick <commit-id> Squash Commit: (Combine multiple commits into a single commit) git merge --squash dev git commit -m "message" (Required after squash merge) Check changes on remote (origin) Git repository: git diff origin/<branch-name> Access remote changes: git merge origin/main git revert: (Undo a commit by creating a new commit) git revert <commit-id> git reset: (Rewrite or remove commit history locally) git reset --soft <commit-id> git reset --mixed <commit-id> git reset --hard <commit-id> After git reset, the commit may still exist on GitHub. To overwrite it: git push --force origin <branch-name> #LeanInPublic #TrainWithShubham #DevOps

Git commands you actually need (and the ones you don't) 🐙 Git has been a part of my life for four years. Without Google, I still don't understand what rebase --interactive does. This is my daily real-world Git workflow: 🚀 The Essentials (Use These Every Day) 1. Start your day git checkout main git pull origin main 2. New feature git checkout -b feature/your-feature-name 3. Check what changed git status git diff 4. Save your work git add . git commit -m "Descriptive message here" 5. Push to remote git push origin feature/your-feature-name 6. Get latest changes (while working) git pull origin main --rebase 🔥 The Fixers (When Things Go Wrong) #Oops, committed to main by accident git reset HEAD~1 #Oops, committed with wrong message git commit --amend -m "New message" #Oops, need to undo that file change git checkout -- filename.js #Oops, need to see who broke this git blame filename.js #Oops, need to temporarily hide work git stash git stash pop 💀 The ones I never use • Git cherry-pick (there's a better way 99 percent of the time) • git reflog (you already know you need this if you need it) • git bisect (great flex, but not useful for day-to-day work) • git submodule (just don't) My philosophy of Git: Make frequent commitments. every fifteen to thirty minutes. Small commits make rollbacks simple. Compose effective messages. "Fix bug" has no purpose."Fix null pointer in user login" is useful. Prior to pushing, pull. Stay informed to prevent merge conflicts. One branch for each feature. Never make a direct commit to main. The One Command That Saved My Career: git reset --hard HEAD When everything breaks and you wish you could go back to the five minutes ago when everything was working. No guilt. 👇 Which Git command do you use the most? Mine is in git status. I actually type it after everything.) #Git #Programming #DevTools #CodingTips #SoftwareEngineering

🚀 PROJECT HIGHLIGHT(CI/CD PIPELINE WITH GITHUB ACTIONS + GITHUB PAGES) It's the weekend, and it's time to put out a simple project for newbies to practice with primary focus on CI/CD. I built an end-to-end CI/CD pipeline for a static React application (restaurant UI with menu, ordering, and user profiles). The goal wasn’t the UI; it was providing automation, reliability, and secure delivery. 🏗️WHAT I IMPLEMENTED - Git workflow with SSH authentication - Automated pipeline triggered on main push - Dependency install with npm ci (reproducible builds) - ESLint linting + Jest tests - Static build + automatic deployment to GitHub Pages 👨💻TECH STACK • Ubuntu 22.04 • Git/GitHub • Node.js 20 • React • GitHub Actions (YAML) • GitHub Pages • Docker (local testing) 🛠️PROBLEMS SOLVED - Fixed deployment permission failure by configuring workflow token scopes - Resolved Node version mismatch between local and CI - Automated lint corrections with pre-commit hooks 📓CHALLENGES & DEBUGGING This project wasn’t just building a pipeline; it was diagnosing real production-style failures. • DEPLOYMENT PERMISSION FAILURE GitHub Actions couldn’t publish to GitHub Pages due to missing repo write access. Fix: Granted GITHUB_TOKEN permissions (contents & pages), pinned action versions, and later used a Personal Access Token (PAT) for reliable deployment. • NODE VERSION MISMATCH Local app worked, but CI builds failed because Actions used an older Node version. Fix: Explicitly set node-version: 20 in the workflow. • NPM DEPENDENCY CONFLICT(ERESOLVE) react-scripts conflicted with the installed TypeScript version. Fix: Downgraded TypeScript to a compatible version and rebuilt lock files. • GIT DIVERGENT BRANCHES Local and remote branches conflicted during pull. Fix: Configured git pull --rebase strategy to maintain a clean commit history. 🤔WHY THIS MATTERS Every commit now lints → tests → builds → deploys automatically. No manual uploads, no environment drift, and failures are caught before release. This project demonstrates: ✔ CI/CD automation ✔ Secure build practices ✔ Debugging production-like failures ✔ Reproducible deployments #DevOps #CICD #GitHubActions #CloudNative #Automation

Most developers can use Git. Fewer understand how it actually works internally. And that gap shows up the moment things go wrong: -> A bad git reset --hard -> A messy rebase -> Duplicate commits after rewriting history -> Lost work after a detached HEAD The turning point for me was this: Git is not a “change tracker.” It’s a content-addressable snapshot database backed by a Directed Acyclic Graph (DAG). Once you internalize that: -> A commit = snapshot + metadata + parent pointer -> A branch = mutable reference to a commit hash -> HEAD = pointer to a reference (or directly to a commit in detached mode) -> Rebase = replaying diffs to create new commits (new hashes) -> Reset = moving a branch reference -> Revert = creating inverse history without rewriting -> Reflog = reference movement journal (your real recovery tool) Git stops feeling magical. It becomes deterministic. I wrote a deep technical breakdown covering: -> How Git constructs the commit DAG -> Why rebasing changes commit identity -> What actually happens in soft vs mixed vs hard reset -> Why merge commits have two parents -> How conflicts arise from overlapping snapshots -> When history rewriting is safe vs dangerous -> How to recover “lost” commits using reflog If you care about clean history, safe collaboration, and understanding what your tooling is doing under the hood — this is for you. 🔗 Read the full guide here: https://lnkd.in/dYWjk3g9 For the engineers here — what’s your rule around rebase vs merge on shared branches? #git #distributedversioncontrol #softwareengineering #devops #backend #engineering

𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗚𝗶𝘁 𝗜𝗻𝘁𝗲𝗿𝗻𝗮𝗹𝘀 Do you struggle with Git? You're not alone. Many developers use Git daily but don't fully understand how it works. This guide is for you. You'll learn about Git reset, rebase, merge, and reflog. Here's what you'll learn: - How Git stores commits - What branches really are - How HEAD works - The difference between git checkout, git reset, and git revert - Merge vs rebase - How to fix merge conflicts - How to recover lost commits using git reflog Git is a content-addressable database of snapshots. Each commit contains: - A full snapshot of your project - Metadata - A pointer to its parent commit - A unique SHA hash A Git branch is just a pointer to a commit. It's not a copy of your code. When you commit, Git creates a new commit and moves the branch pointer forward. HEAD is a special pointer that tracks where you are. Normally, HEAD points to a branch. But if you checkout a specific commit, HEAD points directly to that commit. This is called a detached HEAD state. Git has three internal states: - Working Directory: your actual files - Staging Area: files prepared for next commit - Repository: permanent commit history Understanding Git reset requires understanding these states. There are three types of Git reset: - Soft: moves branch pointer, keeps changes staged - Mixed: moves branch pointer, unstages changes - Hard: moves branch pointer, clears staging area, resets working directory Here's how to use them: - git reset --soft: combine commits - git reset: reorganize commits - git reset --hard: resets working directory (use with caution) To undo changes, use git revert. It creates a new commit that undoes a previous commit. To resolve merge conflicts, edit the file, remove markers, and commit. If you mess up, use git reflog to recover. It's your safety net. For scalable Git workflows, create feature branches, push regularly, and merge into main. Understanding Git internals changes everything. You'll think in commit graphs, understand pointer movement, and choose the right undo strategy. Source: https://lnkd.in/gc2Yfy5n

🚀 Day 24 – Advanced Git: Merge, Rebase, Stash & Cherry-Pick 1️⃣ Git Merge git merge <branch> → Combines another branch into the current branch Fast-forward merge: simple pointer move Merge commit: created when branches diverge ⚠️ Merge conflict → happens when same line is edited in both branches 2️⃣ Git Rebase git rebase <branch> → Reapplies commits on top of another branch Linear history vs merge’s graph-like history 💡 Never rebase shared commits 3️⃣ Squash vs Regular Merge git merge --squash <branch> → Combines multiple commits into one git merge <branch> → Keeps all commits Trade-off: Clean history vs full commit details 4️⃣ Git Stash git stash push -m "message" → Temporarily saves uncommitted work git stash pop → Applies stash and removes it git stash apply → Applies stash without removing it Perfect for context-switching between branches 5️⃣ Git Cherry-Pick git cherry-pick <commit-hash> → Apply a specific commit onto another branch Useful for hotfixes without merging entire branch ✅ Pro Tip: Visualize your history: git log --oneline --graph --all It really helps see merges, rebases, and cherry-picks in action! 💬 Learning Git deeply = less headaches in team projects. #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #ankitaspectrum TrainWithShubham

Git commits: one per task or multiple small commits? This is a common debate in many development teams: 👉 One commit per task vs 👉 Multiple commits with a single responsibility Some teams prefer one commit per task to simplify cherry-picking and releases. Others advocate for multiple small commits, each representing one logical change, which makes reviews, debugging, and reverting much easier. In practice, small focused commits usually lead to better collaboration. This approach aligns with the Single Responsibility Principle (SRP) — applied to commits. **Example** Task: Add customer discount feature **Bad practice — One big commit per task** Single commit: Added discount feature But inside this commit, changes include: - Database schema - API logic - UI forms - Bug fixes - Refactoring - Formatting changes **Problems:** - Hard to review - Hard to revert partially - Hard to debug later - Git history becomes unclear - One commit ≠ One responsibility **Better practice — Split commits by responsibility** Same task, structured commits: - feat(db): add Discount column to Customer table - feat(api): implement discount calculation logic - feat(ui): show discount in customer form - test: add tests for discount calculation - refactor: simplify invoice total calculation Now each commit: - Has one clear responsibility - Is easy to review - Can be reverted safely - Has clear intent - Reduces cherry-pick conflicts Small commits make reviews easier, debugging faster, and collaboration smoother. Clean commit history isn’t just about Git — it’s about helping your future self and your teammates understand what really changed. #Git #SoftwareEngineering #CleanCode #DevWorkflow #VersionControl #Developers

This is good starting point! Another good idea is WIP: End Of Day commits, many times i've seen people crushed over "system updates" or "lost progress" simply because they relied on the stability of their working environments =) Works 99% but that 1% stings...

Most merge conflicts are not really conflicts. Git just *thinks* they are. Traditional Git merging works line-by-line. If two developers touch the same line, Git throws its hands up and asks a human to sort it out. But a lot of those conflicts are actually harmless. One dev changes logic, another adds formatting, and suddenly you’re staring at "<<<<<<< HEAD". So I built IntentMerge. IntentMerge is a CLI that resolves merge conflicts based on code intent, not raw text. Instead of comparing lines, it parses TypeScript/React code into an AST (Abstract Syntax Tree) and analyzes what actually changed. Some examples: • Dev A adds `<Button size="lg" />` • Dev B adds `<Button color="red" />` Git: conflict. IntentMerge: safe automerge. Under the hood it runs a deterministic pipeline: 1. Parse files with `@babel/parser` 2. Normalize ASTs to remove formatting noise 3. Compute structural diffs 4. Classify changes (rename, hook dependency change, JSX prop mutation, logic modification) 5. Apply a strict safety matrix for deterministic auto-merge 6. Validate the merged result with `tsc --noEmit` If something looks dangerous (like both branches modifying the same function logic), IntentMerge refuses to guess. It flags the conflict and explains why. There’s also an LLM advisory mode (Gemini, Groq, or local Ollama) that explains the conflicts and suggests a merge strategy. It never edits code automatically. No hallucinated patches. The goal is simple: Less time resolving fake conflicts. More time shipping code. This is currently an MVP focused on TypeScript + React projects, but the architecture is designed to expand. If you’ve ever spent 20 minutes fixing a merge conflict that shouldn’t have existed, you’ll understand why this tool exists. Curious what people think about AST-based semantic merging becoming part of the standard dev workflow. heres the repo : https://lnkd.in/d8t5kdug

You've typed 𝐠𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 thousands of times. It takes half a second. You've never thought about it. I didn't either. Until I slowed that half second down. Here's what actually happens the moment you press enter: Git doesn't wait for your commit to save your files. They're already saved. The moment you ran 𝐠𝐢𝐭 𝐚𝐝𝐝 : Git compressed your file, computed a hash, and stored it permanently. The commit just organizes what's already there. And here's where it gets beautiful. Git doesn't store file names with file contents. It stores them separately. So if two files across your entire project share identical content: same license header, same config template, Git stores that content exactly once. One object. Referenced from multiple places. No duplication. Ever. Then when you commit one file deep in your project? Git doesn't rewrite everything. It only rewrites the nodes on the path from that file to the root. Your test folder? Untouched. Your docs? Reused. Same hash. Zero cost. Most commits create just a handful of new objects. The rest is pure reuse. And a branch? People imagine branches as parallel universes. Copies of code. Complex structures. A branch is a text file. 40 characters. A hash. A newline. That's it. This is why creating a branch is instantaneous regardless of repo size. Git isn't copying anything. It's writing 41 bytes to disk. The whole system: blobs, trees, commits, branches, is just a folder of compressed text files linked by hashes. No database. No magic. No complexity hiding underneath. Just elegant, intentional simplicity. And the next time you type git commit in half a second you'll know exactly what just happened. That half second contains a masterclass in software design. And this is exactly 𝐰𝐡𝐲 𝐆𝐢𝐭 𝐢𝐬 𝐟𝐚𝐬𝐭. Not because of clever algorithms or powerful hardware. Because it never does work it has already done. Same content → same hash → already stored → skip it. Unchanged files? Reused. Unchanged folders? Reused. New branch? 41 bytes. Git's speed isn't a feature. It's a consequence of the design. Store once. Reference forever. Never repeat. ♻️ Repost if this changed how you see Git. #ai #git #systemdesign #software