Alexander Makoveev’s Post

🚀 𝗚𝗜𝗧 𝗧𝗜𝗣𝗦 – 𝗛𝗼𝘄 𝘁𝗼 𝗨𝗻𝗱𝗼 𝗮 𝘨𝘪𝘵 𝘢𝘥𝘥 (𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗟𝗼𝘀𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗪𝗼𝗿𝗸!) Ever ran 𝘨𝘪𝘵 𝘢𝘥𝘥 too early and wished you could take it back? 😅 Yeah, you can unstage your files easily without losing your changes! Let’s break it down 👇 💡 When you run: 𝘨𝘪𝘵 𝘢𝘥𝘥 <𝘧𝘪𝘭𝘦_𝘯𝘢𝘮𝘦> ➡️ You’re moving changes to the 𝘀𝘁𝗮𝗴𝗶𝗻𝗴 𝗮𝗿𝗲𝗮 (also called the index). If you want to undo it before committing, you can safely remove files from staging while keeping your edits intact. There are 2 simple ways - 🔥 1️⃣ Using 𝘨𝘪𝘵 𝘳𝘦𝘴𝘵𝘰𝘳𝘦 --𝘴𝘵𝘢𝘨𝘦𝘥 (Recommended for modern Git) To unstage a single file:   ⌨️ 𝘨𝘪𝘵 𝘳𝘦𝘴𝘵𝘰𝘳𝘦 --𝘴𝘵𝘢𝘨𝘦𝘥 <𝘧𝘪𝘭𝘦𝘯𝘢𝘮𝘦> To unstage all files in the current directory:   ⌨️ 𝘨𝘪𝘵 𝘳𝘦𝘴𝘵𝘰𝘳𝘦 --𝘴𝘵𝘢𝘨𝘦𝘥 . ✅ Your edits in <filename> remain — only the staging is undone. It’s like saying, “𝘋𝘰𝘯’𝘵 𝘤𝘰𝘮𝘮𝘪𝘵 𝘵𝘩𝘪𝘴 𝘺𝘦𝘵, 𝘣𝘶𝘵 𝘬𝘦𝘦𝘱 𝘮𝘺 𝘸𝘰𝘳𝘬.” 🔥 2️⃣ Using 𝘨𝘪𝘵 𝘳𝘦𝘴𝘦𝘵 (Classic way) To unstage a single file:   ⌨️ 𝘨𝘪𝘵 𝘳𝘦𝘴𝘦𝘵 <𝘧𝘪𝘭𝘦𝘯𝘢𝘮𝘦> To unstage all files:   ⌨️ 𝘨𝘪𝘵 𝘳𝘦𝘴𝘦𝘵 📘 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: You modified 𝘪𝘯𝘥𝘦𝘹.𝘩𝘵𝘮𝘭 and 𝘴𝘵𝘺𝘭𝘦.𝘤𝘴𝘴, then ran:   ⌨️ 𝘨𝘪𝘵 𝘢𝘥𝘥 . But you only wanted to add index.html. To fix that: Option 1️⃣ ⌨️ 𝘨𝘪𝘵 𝘳𝘦𝘴𝘵𝘰𝘳𝘦 --𝘴𝘵𝘢𝘨𝘦𝘥 𝘴𝘵𝘺𝘭𝘦.𝘤𝘴𝘴 Option 2️⃣ ⌨️ 𝘨𝘪𝘵 𝘳𝘦𝘴𝘦𝘵 𝘴𝘵𝘺𝘭𝘦.𝘤𝘴𝘴 Now 𝘴𝘵𝘺𝘭𝘦.𝘤𝘴𝘴 is unstaged but your edits are still there — safe and sound 💪 #Git #GitTips #DevTools #Coding #SoftwareDevelopment #VersionControl #WebDevelopment #DeveloperCommunity #Programming #TechTips

Ever pushed a commit and immediately regretted it because the lint failed or formatting broke? 😅 That’s why I wrote a detailed guide on how to automate code checks before every commit using 👉 Husky + Lint-Staged — with a complete Angular example. In this blog, I’ve covered: 🔹 Step-by-step setup from scratch 🔹 How pre-commit hooks actually work 🔹 Integrating linting & formatting commands 🔹 Ensuring your team commits only clean, tested code 💪 Save time, maintain cleaner commits, and boost your project’s code quality 🚀 🧠 Read the full article here: https://lnkd.in/dAfg9YEb

Git rebase is one of the most powerful yet misunderstood commands in a developer’s toolkit. While many engineers reach for merge by default, mastering when and how to rebase safely can turn a messy commit history into a clean, linear narrative that clearly tells your project’s story. 💡 The golden rule of rebasing Never rebase commits that exist outside your repository, especially those others may have based their work on. Breaking this rule can lead to rewritten history, lost work, and serious team headaches. When to use rebase effectively? -Local cleanup before pushing: Use interactive rebase (git rebase -i) to combine related commits, fix commit messages, and organize work into logical chunks. This helps create a professional-grade commit history before sharing it with your team. -Feature branch integration: Rebasing a feature branch onto main (git rebase main) creates a linear history without merge commit noise making the project timeline cleaner and easier to follow. -Conflict resolution advantages: Rebase surfaces conflicts one commit at a time, making them easier to handle compared to merge’s all-at-once approach. Safety best practices ✅ Always create a backup branch before complex rebases. ✅ Keep interactive sessions small, focus on 3–5 commits for clarity and control. What other useful Git commands have made your workflow smoother? Let’s discuss in the comments 👇 https://lnkd.in/gHZd6f5M #Git #VersionControl #FrontendDevelopment #WebDevelopment #greatfrontend

Learn Git Through Real Practice, Not Simulators I built GitPath because I was frustrated with Git tutorials that either used browser simulators or assumed you already knew what you were doing. GitPath offers 14 hands-on lessons that guide you through real Git commands in your actual terminal. No simulators, no sandboxes - just practical, step-by-step guidance. Creating repositories Staging and committing Branching and merging Undoing changes Working with remotes Rebasing and cherry-picking Clear commands to run Explanations of what's happening Expected outcomes Common mistakes to avoid Simulators are great for visualization, but they don't prepare you for real Git workflows. When you practice with actual Git commands, you build genuine muscle memory. Check it out: gitpath.dev It's free and always will be. Would love your feedback! Built with Next.js, TypeScript, and Tailwind CSS. Deployed on Vercel. https://lnkd.in/gnAigSm6

Git Made Simple 🧩 Over time, Git branches pile up like laundry 🧺 (And trust me, neither looks good when ignored 😄) Here’s a 1-line magic trick to clean up all local branches except the one you’re on: git branch | grep -v "$(git rev-parse --abbrev-ref HEAD)" | xargs git branch -D How it works 🛠️ ---------------- git rev-parse --abbrev-ref HEAD → Gets your current branch grep -v → Excludes it from deletion xargs git branch -D → Deletes all other local branches Why it matters ✅ ------------------ Clears local clutter Leaves remote branches untouched Keeps your repo neat & your mind sane 😌 Clean Git = happy devs! 🚀 #GitTips #DeveloperLife #CleanCode #VersionControl #DevProductivity #Programming #SoftwareEngineering

Ever started coding a new feature… — then realized you were editing main directly? Here’s a quick refresher on the right Git workflow most dev teams use 👇 Always branch off main (or dev) so your work stays isolated. Create a new branch git checkout -b feature/new-feature Push your branch to the remote repo git push -u origin feature/new-feature This sets the upstream so future pushes are easier. Develop & Test your New Feature Make a Pull Request (PR) Head to GitHub/GitLab → click “Compare & pull request.” Add a clear title and description — reviewers will thank you. Merge back into main Once approved, merge via the PR interface or: git checkout main git merge feature/new-feature Sync your local main git checkout main git pull origin main This pulls all new updates so you’re ready for the next feature. 💡 Pro tip: Keep branches short-lived. Smaller PRs = faster reviews + fewer merge conflicts. #Git #DevTips #WebDevelopment #VersionControl

🚀 **Day 44: Git Command Series - `git bisect start`** 🔍 Ever been in that nightmare scenario where a bug mysteriously appeared and you're staring at 10+ commits wondering "WHERE did this go wrong?" 😱 Today's lifesaver: **`git bisect start`** - Your binary search superhero! 🦸♂️ This command begins an automated binary search through your commit history, helping you pinpoint exactly which commit introduced the bug. Instead of manually checking each commit, Git intelligently narrows down the culprit using binary search algorithm! 📊 ## 🎯 **Use Cases:** **🔰 Beginner:** ```bash git bisect start git bisect bad HEAD # Current commit has the bug git bisect good v1.2.0 # This version was working ``` **💪 Seasoned Pro #1:** ```bash git bisect start HEAD feature/auth-update~10 git bisect run npm test # Automated testing for each commit ``` **🚀 Seasoned Pro #2:** ```bash git bisect start --term-new=broken --term-old=working git bisect broken HEAD git bisect working abc123def ``` ## 💡 **Pro Tip to Remember:** Think "**B**inary **S**earch **S**tarts" = **BSS** = "**B**ug **S**earch **S**tarts!" 🧠✨ Perfect for bug archaeology and automated testing workflows! 🕵️♀️ Have you used `git bisect` to solve a tricky bug? Share your experience below! 👇 #Git #SoftwareDevelopment #Debugging #DevTools #TechTips #Programming #Day44 My YT channel Link: https://lnkd.in/d99x27ve

Picture this: It’s 2 AM, you’re rushing to deploy a critical fix, and you accidentally commit code with a glaring syntax error. The CI pipeline fails, your team gets paged, and what should have been a quick fix turns into an hour-long debugging session. Sound familiar? This scenario plays out in development teams worldwide, but it doesn’t have to be your story. Enter Git pre-commit hooks — your automated quality control system that catches issues before they ever leave your local machine. https://lnkd.in/ep7hgnU4

Automate Your Git Workflow with Pre-Commit Hooks Stop breaking your builds with forgotten linting. Your CI/CD isn't the first line of defense; your local Git pre-commit hook is. Developers often skip linters or tests locally. This leads to *broken builds* and wasted time in review. A Git pre-commit hook automates these checks *𝗯𝗲𝗳𝗼𝗿𝗲* your code even leaves your machine. It ensures 𝗰𝗼𝗱𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗮𝘁 𝘁𝗵𝗲 𝘀𝗼𝘂𝗿𝗰𝗲. Implement one in minutes with tools like `husky` or `lint-staged`. Never push a messy commit again. This saves countless hours, keeping your CI/CD green. 🚀🛡️ Guard your codebase. Your team will thank you. What's your favorite pre-commit setup? #gitworkflow #precommit #codequality #cicd #devtools #developer

Why You Should Care About Pre-Commit Hooks (and How Husky Makes It Easier) I thought about writing this because pre-commit checks are one of the most overlooked parts of the development process. Many developers push code straight to GitHub or GitLab without realizing that a simple setup could save them countless hours of debugging and keep their projects clean and consistent. So, let’s talk about pre-commit hooks and how Husky helps make them easy to use. Pre-commit hooks are scripts that run automatically before a Git commit is finalized. They allow you to run checks or commands that ensure your code meets certain standards before it’s saved into the repository. Think of them as automated gatekeepers for your commits. For example, a pre-commit hook can: Run your tests and stop the commit if something fails Lint and format your code automatically Enforce commit message standards Prevent large or sensitive files from being committed The main goal is simple: catch issues early and maintain consistency across your team. Git actually supports hooks nativ https://lnkd.in/gGP-nGt8