5 Essential Git Commands for Developers

🚀 Mastering Unique Git Commands Every Developer Should Know Most developers use Git daily—but only a small percentage go beyond the basic commands like git add, git commit, and git push. Let’s explore some unique and powerful Git commands that can level up your workflow and make you stand out as a developer 💡 🔍 1. git reflog – Your Secret Backup System Ever lost a commit or messed up a branch? 👉 git reflog shows every action you’ve done in your repository—even deleted commits. Why it’s powerful: Recover lost commits Undo hard resets Debug your mistakes 💬 Think of it as your Git “history of history” ⏪ 2. git reset --soft / --mixed / --hard This command is misunderstood but extremely powerful. --soft → Keeps changes staged --mixed → Keeps changes unstaged --hard → Deletes everything (use carefully ⚠️) Use case: Fix wrong commits without losing work. 🧹 3. git clean -fd Want to remove unwanted files? 👉 This deletes: Untracked files Untracked folders Best for: Cleaning messy projects quickly. 🧠 4. git stash – Save Work Without Committing Switching branches but not ready to commit? 👉 Use git stash Save changes temporarily Switch branches safely Reapply later Pro Tip: Use git stash pop to bring changes back. 🔎 5. git bisect – Find Bugs Like a Detective This is one of the most underrated commands. 👉 git bisect helps you: Find the exact commit that introduced a bug Uses binary search internally Why it’s amazing: Saves hours of manual debugging. 🔄 6. git cherry-pick Want to copy a specific commit from another branch? 👉 Use git cherry-pick <commit-id> Use case: Move only important fixes Avoid merging entire branches 🧾 7. git blame Not about blaming people 😄 👉 Shows: Who wrote each line of code When it was written Best for: Understanding legacy code. 🧬 8. git rebase – Clean Commit History Instead of messy merge commits: 👉 Use git rebase Benefits: Cleaner history Linear commit structure Better for collaboration 🌳 9. git log --graph --oneline --all Want to visualize your Git history? 👉 This command shows a beautiful tree view Why it’s useful: Understand branches easily Track merges visually 🔐 10. git commit --amend Made a mistake in your last commit? 👉 Fix it without creating a new commit. Use case: Update commit message Add missed changes 💡 Final Thought Git is not just a version control tool—it’s a powerful time machine. Most developers only use 20% of Git’s capabilities. But mastering these unique commands can: ✔ Save time ✔ Reduce errors ✔ Make you a better engineer 🔥 Hashtags for LinkedIn #Git #SoftwareEngineering #Developers #Coding #TechTips #VersionControl #Programming #LearnGit #DeveloperTools #CareerGrowth

🚀 How Git Actually Works? When I first started using Git, I used commands like "git add", "git commit", and "git push"… but I didn’t really understand what was happening behind the scenes. Here’s a simple breakdown that made everything click for me 👇 🔍 1. Git is a Snapshot Tracker (Not File Storage) Git doesn’t store changes like “line-by-line edits” (like we often think). Instead, it stores snapshots of your project at different points in time. 👉 Example: - You create "index.html" - You commit it → Git stores a snapshot - You edit it again → Git stores a new snapshot Think of it like a timeline of your project 📸 📦 2. The 3 Main Areas in Git Git works with 3 key areas: 1. Working Directory → where you write code 2. Staging Area (Index) → where you prepare changes 3. Repository (.git folder) → where commits are stored 👉 Example workflow: # Step 1: Modify a file edit app.py # Step 2: Add to staging git add app.py # Step 3: Save snapshot git commit -m "Added login logic" ✔️ Now Git stores a snapshot of your project with that message. 🌳 3. Commits Form a Tree (Not Just a List) Each commit has: - A unique ID (hash) - A reference to the previous commit 👉 Example: A → B → C If you create a new branch: A → B → C (main) \ D → E (feature) This is why Git is so powerful for parallel development 💡 🌿 4. Branching = Lightweight Copy Branches are just pointers to commits, not full copies of your project. 👉 Example: git branch feature-login git checkout feature-login Now you're working on a separate line of development without affecting "main". 🔄 5. Merging Changes When your feature is ready: git checkout main git merge feature-login Git combines histories of both branches. ✔️ If changes don’t conflict → automatic merge ❗ If conflicts → you resolve manually ☁️ 6. Git vs GitHub (Important!) - Git → version control system (runs locally) - GitHub → cloud platform to store and share repos 👉 Example: git push origin main This uploads your local commits to GitHub. 🧠 Final Thought Git is not just a tool — it’s a time machine for your code ⏳ Once you understand: - snapshots - staging - commits - branches Everything becomes much easier and more predictable. #Git #VersionControl #Programming #Developers #LearningJourney

Today I've watched a couple of videos on youtube , the content related to git and git hub, these are the couple of things I have understood . Git and GitHub Fundamentals Git is a distributed version control system that tracks changes in project files, maintaining a detailed history of who made which changes and when   . GitHub is a popular online platform that hosts Git repositories, enabling developers worldwide to share, collaborate on, and contribute to projects, especially open-source ones. Repositories: Local vs. Remote A repository is essentially a project folder where Git tracks all changes, maintaining a complete history of file creations, modifications, and deletions. A local repository resides on your personal machine, while a remote repository is hosted online, typically on platforms like GitHub. Basic Git Workflow The fundamental Git workflow involves tracking changes, staging them, and then committing them to the project's history. git status: This command shows the current state of your working directory, listing files that have been created, modified, or deleted but are not yet saved in the project's history   . git add <file> or git add .: This command stages changes, preparing them to be included in the next commit. It moves files from an "untracked" or "modified" state to the "staged" area   . git commit -m "message": This command saves all staged changes to the repository's history, along with a descriptive message explaining the changes made  . After a commit, git status should show "nothing to commit". Viewing and Undoing Changes git log: Displays the project's commit history, showing each commit's unique ID, author, date, and message  . git restore <file>: Discards uncommitted changes in your working directory for a specific file, reverting it to its last committed state or unstaging it. git reset <commit_hash>: Moves the HEAD pointer to a previous commit, effectively undoing subsequent commits and removing them from the project's history  git stash: Temporarily saves uncommitted changes (both staged and unstaged) to a "stash" pile, allowing you to switch contexts or branches without committing incomplete work. These changes can be reapplied later. #DevOps #Git #GitHub #VersionControl #CI_CD #RemoteJobs #CloudComputing #TechCareers #OpenSource

Most beginners confuse Git and GitHub. They are NOT the same thing. 🙅 Here's everything you need to know 👇 🔴 𝗚𝗶𝘁 — 𝗩𝗲𝗿𝘀𝗶𝗼𝗻 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗦𝘆𝘀𝘁𝗲𝗺 ∟ Tracks every change in your code ∟ Lives on YOUR computer locally ∟ Allows you to go back to any version ∟ Works completely offline ✅ 🐙 𝗚𝗶𝘁𝗛𝘂𝗯 — 𝗖𝗼𝗱𝗲 𝗛𝗼𝘀𝘁𝗶𝗻𝗴 𝗣𝗹𝗮𝘁𝗳𝗼𝗿𝗺 ∟ Cloud storage for your Git repositories ∟ Enables team collaboration & social coding ∟ Stores your code remotely & safely ☁️ ⚙️ 𝗚𝗶𝘁𝗛𝘂𝗯 𝗔𝗰𝘁𝗶𝗼𝗻𝘀 — 𝗖𝗜/𝗖𝗗 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 ∟ Automates your entire workflow ∟ Runs tests, builds & deploys automatically ∟ Zero manual deployment needed 🚀 📋 𝗚𝗶𝘁 𝗖𝗼𝗺𝗺𝗮𝗻𝗱𝘀 𝗘𝘃𝗲𝗿𝘆 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗠𝘂𝘀𝘁 𝗞𝗻𝗼𝘄 👇 🟢 𝗦𝗲𝘁𝘂𝗽 & 𝗜𝗻𝗶𝘁𝗶𝗮𝗹𝗶𝘇𝗲 𝙜𝙞𝙩 𝙞𝙣𝙞𝙩     # Start a new repo 𝙜𝙞𝙩 𝙘𝙡𝙤𝙣𝙚 <𝙪𝙧𝙡>  # Copy a remote repo 🔵 𝗗𝗮𝗶𝗹𝘆 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝙜𝙞𝙩 𝙨𝙩𝙖𝙩𝙪𝙨    # Check current state 𝙜𝙞𝙩 𝙖𝙙𝙙 <𝙛𝙞𝙡𝙚>  # Stage a file 𝙜𝙞𝙩 𝙖𝙙𝙙 .     # Stage everything 𝙜𝙞𝙩 𝙘𝙤𝙢𝙢𝙞𝙩 -𝙢 "" # Save with message 🟠 𝗕𝗿𝗮𝗻𝗰𝗵𝗲𝘀 𝙜𝙞𝙩 𝙗𝙧𝙖𝙣𝙘𝙝      # List all branches 𝙜𝙞𝙩 𝙗𝙧𝙖𝙣𝙘𝙝 <𝙣𝙖𝙢𝙚>  # Create new branch 𝙜𝙞𝙩 𝙘𝙝𝙚𝙘𝙠𝙤𝙪𝙩 <𝙣𝙖𝙢𝙚> # Switch branch 𝙜𝙞𝙩 𝙘𝙝𝙚𝙘𝙠𝙤𝙪𝙩 -𝙗   # Create + switch 🔴 𝗦𝗲𝗻𝗱 𝗖𝗵𝗮𝗻𝗴𝗲𝘀 𝙜𝙞𝙩 𝙥𝙪𝙨𝙝 𝙤𝙧𝙞𝙜𝙞𝙣 <𝙗𝙧𝙖𝙣𝙘𝙝> # Push to remote 𝙜𝙞𝙩 𝙥𝙪𝙡𝙡 𝙤𝙧𝙞𝙜𝙞𝙣 <𝙗𝙧𝙖𝙣𝙘𝙝> # Fetch + merge 𝙜𝙞𝙩 𝙛𝙚𝙩𝙘𝙝 𝙤𝙧𝙞𝙜𝙞𝙣     # Download only 🟣 𝗨𝗻𝗱𝗼 & 𝗥𝗲𝘀𝗲𝘁 𝙜𝙞𝙩 𝙧𝙚𝙨𝙩𝙤𝙧𝙚 <𝙛𝙞𝙡𝙚>   # Discard changes 𝙜𝙞𝙩 𝙧𝙚𝙨𝙚𝙩 --𝙨𝙤𝙛𝙩    # Keep changes 𝙜𝙞𝙩 𝙧𝙚𝙨𝙚𝙩 --𝙝𝙖𝙧𝙙    # Delete changes ⚠️ 🟡 𝗛𝗶𝘀𝘁𝗼𝗿𝘆 & 𝗖𝗼𝗺𝗽𝗮𝗿𝗶𝘀𝗼𝗻 𝙜𝙞𝙩 𝙡𝙤𝙜       # Full commit history 𝙜𝙞𝙩 𝙙𝙞𝙛𝙛       # See all changes 𝙜𝙞𝙩 𝙙𝙞𝙛𝙛 --𝙨𝙩𝙖𝙜𝙚𝙙  # Staged vs last commit 𝙜𝙞𝙩 𝙨𝙝𝙤𝙬 <𝙞𝙙>    # Details of a commit ⚫ 𝗦𝘁𝗮𝘀𝗵 (𝗦𝗮𝘃𝗲 𝗪𝗼𝗿𝗸 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗿𝗶𝗹𝘆) 𝙜𝙞𝙩 𝙨𝙩𝙖𝙨𝙝    # Save current changes 𝙜𝙞𝙩 𝙨𝙩𝙖𝙨𝙝 𝙡𝙞𝙨𝙩 # View all stashes 𝙜𝙞𝙩 𝙨𝙩𝙖𝙨𝙝 𝙥𝙤𝙥  # Apply & remove stash 🔄 The 4 Steps to Push Code to GitHub 1️⃣ SAVE  → Save files in your editor 2️⃣ ADD  → git add . (stage changes) 3️⃣ COMMIT → git commit -m "your message" 4️⃣ PUSH  → git push origin <branch> That's it. Save → Add → Commit → Push ✅ Git is the tool. GitHub is where you store the work. GitHub Actions is how you automate it. 💪 Every developer needs all three. 🎯 Save this 🔖 — your complete Git cheat sheet is now ready. Follow for daily coding tips & developer resources. 💡 #Git #GitHub #Coding #Programming #WebDevelopment #DevOps #SoftwareEngineering #Tech #LearnToCode #Developer

Most developers think of Git as a "save button" for code. In reality, it is a sophisticated 𝘁𝗵𝗿𝗲𝗲-𝘁𝗶𝗲𝗿𝗲𝗱 𝘀𝘁𝗮𝗴𝗶𝗻𝗴 𝗲𝗻𝗴𝗶𝗻𝗲 designed to prevent mistakes before they become permanent. 🛡️ As 𝗠𝗮𝗿𝘁𝗶𝗻 𝗙𝗼𝘄𝗹𝗲𝗿, a pioneer in software architecture and continuous integration, emphasizes: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." In Git, that understanding starts with how you organize your changes before you hit "commit." 𝗧𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗭𝗼𝗻𝗲𝘀: 𝗪𝗵𝗲𝗿𝗲 𝗬𝗼𝘂𝗿 𝗖𝗼𝗱𝗲 𝗟𝗶𝘃𝗲𝘀 Your project exists in three distinct states simultaneously:  1. 𝗪𝗼𝗿𝗸𝗶𝗻𝗴 𝗗𝗶𝗿𝗲𝗰𝘁𝗼𝗿𝘆 (𝗧𝗵𝗲 𝗦𝗮𝗻𝗱𝗯𝗼𝘅): This is your local project folder. Here, files are either 𝗨𝗻𝘁𝗿𝗮𝗰𝗸𝗲𝗱 (new files Git doesn't know yet) or 𝗠𝗼𝗱𝗶𝗳𝗶𝗲𝗱 (existing files you’ve edited). It’s a place for messy, raw experimentation.  2. 𝗦𝘁𝗮𝗴𝗶𝗻𝗴 𝗔𝗿𝗲𝗮 / 𝗜𝗻𝗱𝗲𝘅 (𝗧𝗵𝗲 𝗕𝘂𝗳𝗳𝗲𝗿): This is the "Pre-flight Check." It’s a middle ground where you organize your work. You don't have to commit everything you’ve changed—only what is ready. It isolates specific changes to ensure your history remains clean.  3. 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆 (𝗧𝗵𝗲 𝗧𝗶𝗺𝗲𝗹𝗶𝗻𝗲): Once you commit, your changes enter the 𝗖𝗼𝗺𝗺𝗶𝘁𝘁𝗲𝗱 state. This is the official, permanent history of the project. 𝗧𝗵𝗲 𝗘𝘀𝘀𝗲𝗻𝘁𝗶𝗮𝗹 𝗖𝗼𝗺𝗺𝗮𝗻𝗱 𝗟𝗼𝗼𝗽  • 𝗴𝗶𝘁 𝘀𝘁𝗮𝘁𝘂𝘀: Your compass. Always run this first to identify your current state and next action.  • 𝗴𝗶𝘁 𝗮𝗱𝗱 <𝗳𝗶𝗹𝗲>: The act of intentional selection. You are moving changes into the staging area.  • 𝗴𝗶𝘁 𝗰𝗼𝗺𝗺𝗶𝘁 -𝗺 "𝗱𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻": Locking the door. This attaches a permanent message to your snapshot, telling the story of why the change happened. 𝗧𝗵𝗲 "𝗔𝘁𝗼𝗺𝗶𝗰" 𝗠𝗶𝗻𝗱𝘀𝗲𝘁: 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀 Professional Git usage isn't about storage; it’s about 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻.  • 𝗔𝘁𝗼𝗺𝗶𝗰 𝗖𝗼𝗺𝗺𝗶𝘁𝘀: Group your changes into small, logical units. If you fixed a bug and added a feature, that should be two commits, not one. This makes debugging and "reverting" much easier.  • 𝗣𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹 𝗠𝗲𝘀𝘀𝗮𝗴𝗶𝗻𝗴: Avoid vague text like "fixed stuff." Your commit messages should tell the story. A year from now, you (or your successor) should be able to read the history and understand the evolution of the logic. 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Git gives you a buffer zone for a reason. Use the Staging Area to curate your work. Don't just save your code—document your progress. 𝗔𝗿𝗲 𝘆𝗼𝘂𝗿 𝗰𝗼𝗺𝗺𝗶𝘁𝘀 𝘁𝗲𝗹𝗹𝗶𝗻𝗴 𝗮 𝗰𝗹𝗲𝗮𝗿 𝘀𝘁𝗼𝗿𝘆, 𝗼𝗿 𝗮𝗿𝗲 𝘁𝗵𝗲𝘆 𝗮 𝗺𝗲𝘀𝘀𝘆 "𝘃𝟮_𝗳𝗶𝗻𝗮𝗹" 𝗹𝗼𝗴? #Git #SoftwareEngineering #CleanCode #DevOps #ProgrammingTips #WebDevelopment

Day 2 of #30DaysOfDevOps — Post 2 Once you know basic Git, the next step is learning how to use it like a pro. These are the commands that separate junior engineers from senior ones. 1. Git Rebase Merge creates a new commit tying two branches together. Rebase moves your entire branch on top of another — keeping history straight and clean. git checkout feature/api-refactor git rebase main Your commits get replayed one by one on top of main. No messy merge commits cluttering the log. 2. Interactive Rebase Before merging, clean up your commit history so reviewers don't see every "fix typo" and "oops" commit. git rebase -i HEAD~4 In the editor: - squash — combine commits into one - reword — rename a commit message - drop — remove a commit entirely A clean history is a sign of a professional engineer. 3. Git Cherry-pick Need just one commit from another branch? Don't merge the whole thing. git checkout release/v2.1 git cherry-pick 7d3f91b That single commit is now applied to your current branch. Perfect for backporting a hotfix. 4. Amending Commits Caught a mistake right after committing? Fix it before pushing. Wrong message: git commit --amend -m "Add rate limiting to auth endpoint" Forgot a file: git add middleware/ratelimit.js git commit --amend --no-edit Rule: never amend a commit that's already on a shared branch. 5. Reset vs Revert Two ways to undo — very different consequences. git reset --soft HEAD~1 — undo commit, keep changes staged git reset --mixed HEAD~1 — undo commit, keep changes unstaged git reset --hard HEAD~1 — undo commit and wipe all changes git revert HEAD — create a new commit that undoes the previous one On shared branches, always use revert. Reset rewrites history — dangerous for teammates. 6. Git Stash Need to switch branches but not ready to commit? Stash your work. git stash git checkout main Come back later and restore it: git stash pop You can have multiple stashes and name them too: git stash save "half-done login validation" 7. Git Hooks Hooks run scripts automatically at key Git events. A pre-commit hook can enforce code quality before anything gets committed. cd .git/hooks nano pre-commit #!/bin/bash echo "Running lint check..." npm run lint if [ $? -ne 0 ]; then  echo "Lint failed. Commit blocked."  exit 1 fi chmod +x pre-commit Now no one on your team can commit broken code. 8. Challenges for Today 1. Rebase a feature branch on top of main and verify the log looks linear. 2. Use interactive rebase to squash 4 commits into a single meaningful commit. 3. Cherry-pick a bug fix commit from one branch and apply it to another. 4. Practice all three reset modes and observe how your working directory changes. Drop your solutions or questions in the comments. #DevOps #Git #GitHub #30DaysOfDevOps #LearningInPublic #DevOpsEngineer #CloudComputing

𝗧𝗵𝗮𝘁 "𝗪𝗵𝗮𝘁 𝗱𝗶𝗱 𝗜 𝗲𝘃𝗲𝗻 𝗱𝗼 𝗵𝗲𝗿𝗲?" 𝗳𝗲𝗲𝗹𝗶𝗻𝗴 𝘄𝗵𝗲𝗻 𝗹𝗼𝗼𝗸𝗶𝗻𝗴 𝗮𝘁 𝗼𝗹𝗱 𝗰𝗼𝗺𝗺𝗶𝘁𝘀 𝗶𝘀 𝘁𝗵𝗲 𝘄𝗼𝗿𝘀𝘁. 🤦♂️ We’ve all been there: scrolling through a Git history filled with "updates," "fix," or "temp," and even the person who wrote it has no idea what changed. To solve this, I’ve started using a customized CommitLint configuration. No more guessing—just clean, structured, and searchable history. 🚀 𝗪𝗵𝘆 𝘂𝘀𝗲 𝗖𝗼𝗺𝗺𝗶𝘁𝗟𝗶𝗻𝘁? It acts as a gatekeeper for your Git messages. If the commit doesn't follow the rules, it doesn't get in. It forces the team (and my future self) to be intentional. By default, CommitLint is a strict gatekeeper. If your message doesn't follow the type(scope): subject format, it stops the commit entirely. No exceptions. 𝘽𝙪𝙩 𝙄 𝙙𝙞𝙙𝙣'𝙩 𝙨𝙩𝙤𝙥 𝙖𝙩 𝙩𝙝𝙚 𝙙𝙚𝙛𝙖𝙪𝙡𝙩𝙨. 𝙄’𝙫𝙚 𝙖𝙙𝙙𝙚𝙙 𝙘𝙪𝙨𝙩𝙤𝙢𝙞𝙯𝙖𝙩𝙞𝙤𝙣𝙨 𝙩𝙤 𝙛𝙞𝙩 𝙢𝙮 𝙨𝙥𝙚𝙘𝙞𝙛𝙞𝙘 𝙥𝙧𝙤𝙟𝙚𝙘𝙩 𝙣𝙚𝙚𝙙𝙨: ✅ 𝗖𝘂𝘀𝘁𝗼𝗺 𝗧𝘆𝗽𝗲𝘀: Added specific types like perf for performance and build for dependency shifts. ✅ 𝗦𝗰𝗼𝗽𝗲 𝗘𝗻𝗳𝗼𝗿𝗰𝗲𝗺𝗲𝗻𝘁: Forced the use of scopes (like auth, api, or ui) so I know exactly where the change happened at a glance. ✅ 𝗛𝗲𝗮𝗱𝗲𝗿 𝗟𝗲𝗻𝗴𝘁𝗵: Capped headers at 100 characters to keep the Git history readable. 𝗧𝗵𝗲 𝗖𝗹𝗲𝗮𝗻 𝗦𝗲𝘁𝘂𝗽: 𝗡𝗮𝘁𝗶𝘃𝗲 .𝗴𝗶𝘁𝗵𝗼𝗼𝗸𝘀 ⚓ While many developers use the Husky npm package for this, I preferred a more lightweight approach. I’ve used a custom .githooks folder in my project root to manage the hooks directly. This keeps the repo clean and ensures the rules are enforced the moment you hit `git commit`. 𝗧𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁? 𝗔 𝗚𝗶𝘁 𝗵𝗶𝘀𝘁𝗼𝗿𝘆 𝘁𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘁𝗲𝗹𝗹𝘀 𝗮 𝘀𝘁𝗼𝗿𝘆: feat(auth): add user registration fix(api): resolve pagination issue refactor(payments): simplify checkout logic 𝗪𝗮𝗻𝘁 𝘁𝗼 𝘀𝗲𝗲 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝘀𝗲𝘁𝘂𝗽? 📖 Read about my customization here: https://lnkd.in/dhgWjZvi 🛠️ Grab the config file here (i have commented some lines, to not make it super strict but you can try things): https://lnkd.in/dCM3QHkU Stop treating your commit history like the "wild west." Start building a legacy of clean code! 🛠️✨ Do you prefer a native .githooks approach or do you stick with Husky? Let’s talk below! 👇 #Git #CommitLint #Github #BitBucket #Gitlab #CleanCode #WebDevelopment #ProgrammingTips #SoftwareEngineering #DevTools #OpenSource #Backend #DevOps #Github

🚀 Some Helpful Practical Git Commands That Could Save You Headaches One thing I’ve learned about working with Git is that real understanding comes from being hands-on - especially when you’re working in a highly evolving repository or fast-moving project with frequent edits from multiple engineers. In such environments, the chances of running into a Git block are always high. Have you ever finished working on a feature, ready to commit… only to realise the repo has moved ahead since your last pull? 😅 Merge conflicts, rejected pushes, messy history - we’ve all been there. Here are some practical Git commands that often come to my rescue 👇 🔄 Sync your branch with latest remote changes git pull origin <branch> Fetches and merges the latest changes from the remote branch into your current branch. 🧹 Rebase your work on top of latest main/master git rebase origin/master Reapplies your local commits on top of the latest master. This helps maintain a clean linear history and reduces noisy merge commits. ✏️ Clean up commit history before pushing git rebase -i HEAD~3 Interactive rebase for the last 3 commits. Useful to: squash commits reword commit messages reorder commits drop unnecessary commits Great for polishing your branch before opening a PR. ⏪ Move branch pointer but keep your changes staged git reset --soft origin/master Resets your current branch to match origin/master without losing your local changes. Perfect when you want to recreate commits cleanly after syncing. ✅ Create a meaningful commit git commit -m "feat(4996): add meaningful description" Structured commit messages help: reviewers understand intent future debugging generating release notes 🚀 Force push updated history (use carefully!) git push origin <feature-branch> --force Pushes rewritten history after a rebase or amend. ⚠️ Use responsibly - avoid if others are working on the same branch. 🌿 Switch back to main branch git checkout master 🧨 Delete local feature branch git branch -D <feature-branch> Cleans up branches that are no longer needed. 👤 Fix commit author details git commit --amend --author="Your Name <email>" Updates the author metadata of the latest commit - useful after pairing, rebasing, or using a different machine. 🔁 Push amended commit git push --force Required after changing commit history (like amend or rebase). 💡 Key takeaway: Git mastery doesn’t come from memorising commands - it comes from navigating real problems in real repos. The more collaborative and fast-moving your project is, the more you’ll appreciate these workflows. Curious to hear from other engineers 👇 👉 What Git commands save you the most time or headaches? #Git #SoftwareEngineering #DeveloperExperience #TechTips #VersionControl

While working with Git Submodules, one question kept hitting me: "If a private/public package can manage versions and share code — why should I use Git Submodule?" Turns out — it's not a tooling decision. It's an architecture decision. You don't choose Git Submodule vs Public/Private Package by preference… You choose it by asking the right questions 👇 ― 🧠 Reusability & Ownership Will this be reused across projects? 👉 YES → Public/Private Package | NO → Git Submodule 🔄 Versioning Do you need versions (1.0.0)? Different apps using different versions? 👉 YES → Public/Private Package | NO → Git Submodule ⚙️ Updates Frequent changes with controlled releases? 👉 YES → Public/Private Package | NO → Git Submodule 👥 Scaling Multiple teams or future growth expected? 👉 YES → Public/Private Package | NO → Git Submodule 🔗 Dependencies Does it depend on other libraries? 👉 YES → Public/Private Package | NO → Git Submodule 🧩 Coupling (most important) Tightly coupled to one app only? 👉 YES → Git Submodule | NO → Public/Private Package 👨👩👦 Team Adaptation Is your team already confident with Git workflows? 👉 NO → Public/Private Package Git Submodules introduce a non-trivial learning curve: • Developers must remember to run git submodule update --init after every clone • Forgetting this = empty folders and confusing build errors • Pushing changes requires awareness of both the submodule repo and the parent repo • One wrong move can leave the team on a detached HEAD without knowing it If your team is still building Git confidence — Git Submodules will slow everyone down. ― 🔍 Debugging This is where the two approaches feel completely different. 🔨 Git Submodule The full source code lives inside your project. You can set a breakpoint directly inside the shared module, step through it line by line, and see exactly what’s happening — without leaving your IDE. 📦 Public/Private Package You see the crash. But you can’t step into it. 👉 If deep debugging of shared code is part of your daily workflow — Git Submodule has a real advantage here. ― 📦 Real Example: Networking Layer Building a networking layer for your app? • Reusable across multiple apps, versioned, shared across teams? 👉 Public/Private Package • Tightly coupled to one app with custom endpoints and app-specific logic? 👉 Git Submodule (or even same repo) is enough ― 📖 Want to dive deeper into Git Submodules? The official Pro Git book covers everything you need to know: https://lnkd.in/dQHjkj5E #SoftwareArchitecture #Git #MobileDev #iOS #Android #TechLeadership #DevTips

🚨 𝗚𝗶𝘁 𝗶𝗻 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗜𝘀 𝗡𝗼𝘁 𝗔𝗯𝗼𝘂𝘁 "𝘨𝘪𝘵 𝘢𝘥𝘥 ." If you're a senior developer, Git is not a tool. It’s a risk management system. Let me show you with REAL production scenarios 👇 1️⃣ 𝗴𝗶𝘁 𝗿𝗲𝘃𝗲𝗿𝘁 — 𝗪𝗵𝗲𝗻 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗜𝘀 𝗢𝗻 𝗙𝗶𝗿𝗲 🔥 Scenario: You deploy a new payment update. Suddenly users can’t complete checkout. Revenue is bleeding every minute. You DO NOT rewrite history. 𝗬𝗼𝘂 𝗿𝘂𝗻: git revert <commit-hash> 𝘨𝘪𝘵 𝘱𝘶𝘴𝘩 ✅ Creates a new commit that undoes the damage ✅ Safe for shared branches ✅ CI/CD triggers redeploy This is how seniors fix production without panic. 2️⃣ 𝗴𝗶𝘁 𝗰𝗵𝗲𝗿𝗿𝘆-𝗽𝗶𝗰𝗸 — 𝗦𝘂𝗿𝗴𝗶𝗰𝗮𝗹 𝗛𝗼𝘁𝗳𝗶𝘅 Scenario: A security fix was merged in development. But you cannot deploy the whole branch to production. You only need that one fix. 𝘨𝘪𝘵 𝘤𝘩𝘦𝘳𝘳𝘺-𝘱𝘪𝘤𝘬 <𝘴𝘦𝘤𝘶𝘳𝘪𝘵𝘺-𝘧𝘪𝘹-𝘩𝘢𝘴𝘩> 🎯 Result:  • Only that commit goes to main  • No risky features included  • Minimal blast radius That’s how you protect stability. 3️⃣ 𝗴𝗶𝘁 𝗿𝗲𝗯𝗮𝘀𝗲 — 𝗖𝗹𝗲𝗮𝗻 𝗛𝗶𝘀𝘁𝗼𝗿𝘆 𝗕𝗲𝗳𝗼𝗿𝗲 𝗣𝗥 Scenario: You worked 6 days on a feature branch. Meanwhile, 𝗺𝗮𝗶𝗻 moved forward with 40 commits. Instead of messy merge commits: 𝘨𝘪𝘵 𝘳𝘦𝘣𝘢𝘴𝘦 𝘮𝘢𝘪𝘯 Why? Because when debugging production later, clean history saves HOURS. Messy history = painful debugging. 4️⃣ 𝗴𝗶𝘁 𝗯𝗶𝘀𝗲𝗰𝘁 — 𝗙𝗶𝗻𝗱 𝘁𝗵𝗲 𝗞𝗶𝗹𝗹𝗲𝗿 𝗖𝗼𝗺𝗺𝗶𝘁 Scenario: App was working last week. Now login randomly fails. There are 300 commits. Instead of guessing: 𝘨𝘪𝘵 𝘣𝘪𝘴𝘦𝘤𝘵 𝘴𝘵𝘢𝘳𝘵 𝘨𝘪𝘵 𝘣𝘪𝘴𝘦𝘤𝘵 𝘣𝘢𝘥 𝘨𝘪𝘵 𝘣𝘪𝘴𝘦𝘤𝘵 𝘨𝘰𝘰𝘥 <𝘭𝘢𝘴𝘵-𝘸𝘰𝘳𝘬𝘪𝘯𝘨-𝘤𝘰𝘮𝘮𝘪𝘵> Git binary-searches your history. Within minutes → you know exactly which commit broke it. That’s senior-level debugging. 5️⃣ 𝗴𝗶𝘁 𝗿𝗲𝗳𝗹𝗼𝗴 — 𝗪𝗵𝗲𝗻 𝗬𝗼𝘂 𝗔𝗰𝗰𝗶𝗱𝗲𝗻𝘁𝗮𝗹𝗹𝘆 𝗗𝗲𝘀𝘁𝗿𝗼𝘆 𝗪𝗼𝗿𝗸 😬 You run: 𝘨𝘪𝘵 𝘳𝘦𝘴𝘦𝘵 --𝘩𝘢𝘳𝘥 And realize… You just deleted 2 days of work. Most juniors panic. Senior dev runs: 𝘨𝘪𝘵 𝘳𝘦𝘧𝘭𝘰𝘨 Finds previous HEAD → restores everything. Career saved. 6️⃣ 𝗴𝗶𝘁 𝘀𝘁𝗮𝘀𝗵 — 𝗘𝗺𝗲𝗿𝗴𝗲𝗻𝗰𝘆 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗦𝘄𝗶𝘁𝗰𝗵𝗶𝗻𝗴 Scenario: You’re mid-feature. CEO reports production bug. You can’t commit half-baked code. 𝘨𝘪𝘵 𝘴𝘵𝘢𝘴𝘩 𝘨𝘪𝘵 𝘤𝘩𝘦𝘤𝘬𝘰𝘶𝘵 𝘮𝘢𝘪𝘯 Fix → push → return to work: 𝘨𝘪𝘵 𝘴𝘵𝘢𝘴𝘩 𝘱𝘰𝘱 This is how real release engineering works. 💡 What Juniors Think Git Is: Add → Commit → Push 💡 What Seniors Know Git Is:  1. Risk control  2. Recovery system  3. Production insurance  4. Debugging weapon If you’re aiming for senior roles, master these commands. Not theoretically. In real-world production scenarios. 💬 Which Git command saved you in production once? Drop it below 👇 #Git #SeniorDeveloper #EngineeringLeadership #CareerGrowth #TechCareers #DeveloperLife #DevCommunity #DAY77