Mastering Git Workflow: Essential Commands for Devs

If your Git & GitHub workflow feels chaotic, this is how you fix it. Here’s a simple, production-ready setup that gives you real results, not just rules: ✅ Cleaner commit history So you instantly understand what changed and why — even months later. ✅ Fewer bugs reaching production Because nothing goes to main without a pull request and automated checks. ✅ Faster code reviews Clear PR templates + labels = less back-and-forth, more signal. ✅ Confidence while deploying You always know what’s in main and what’s still in progress. The core setup (easy to follow) • main → production-ready • develop → active work • feature/*, bugfix/*, hotfix/* Commit messages that actually help Instead of: ❌ “fix bug” Use: ✔ fix(cart): correct total price calculation ✔ feat(auth): add OTP login Labels that save time (not waste it) • type: bug / feature / refactor • priority: high / medium / low • status: in-progress / blocked / ready Now issues tell a story at a glance. Automation that protects you Every pull request automatically: • installs dependencies • runs tests • blocks broken code from merging No memory. No reminders. Just safety. Works for everyone Solo developer? You get clarity, safety, and future-proof history. Team developer? You get predictable reviews, fewer conflicts, and calmer releases. This is the kind of Git setup that disappears into the background and lets you focus on building. If your current workflow causes: • stress before merges • fear of breaking production • confusion in Git history It’s time to simplify. How do you currently manage Git in your projects? #Git #GitHub #SoftwareEngineering #DeveloperProductivity #WebDevelopment Read full blog post here: https://lnkd.in/gSthbtmg

WHEN SHOULD I USE THESE GIT COMMANDS? GIT COMMANDS CHEAT SHEET FOR BEGINNERS 1. git init • Start a new local Git repository 2. git clone <url> • Copy an existing remote repository to your computer 3. git add <file> or git add . • Stage changes (tell Git which files to include in the next commit) 4. git commit -m "Your message" • Save a snapshot of your staged changes with a message 5. git branch • List, create, or delete branches 6. git checkout -b <branch-name> or git switch -c <branch-name> • Create and switch to a new branch 7. git checkout <branch-name> or git switch <branch-name> • Switch between branches 8. git merge <branch-name> • Combine changes from one branch into your current branch 9. git push origin <branch-name> • Upload your local commits to the remote repository 10. git pull • Fetch latest changes from remote and merge them into your current branch 11. git status • Show what files are changed, staged, or untracked 12. git log • View commit history Quick Workflow Most Teams Use Daily: 1. git pull origin main Get latest code 2. git checkout -b feature/new-login Start your work 3. (code, code, code...) 4. git add . Stage everything 5. git commit -m "Add login page" Save your work 6. git push origin feature/new-login Share it 7. Create Pull Request on GitHub/GitLab 8. After review & approval merge into main Happy coding,! 🚀 #Git #DevOps #90DaysOfDevOps

 Git & GitHub | Merge Conflict During Pull 🚨 Common Team Issue: Merge conflict while pulling code Merge conflicts are one of the most frequent challenges developers face when working in shared repositories—especially when multiple people modify the same files Typical error: CONFLICT (content): Merge conflict in app.py This usually happens when Git is unable to automatically merge changes from different branches. Basic commands involved in resolving conflicts: 1. git pull: You initiate the update, and Git informs you of the conflict. 2. git status: Always your friend! It shows you which files are in conflict. 3. Open the Conflicted File: You'll see special markers (<<<<<<<, =======, >>>>>>>) indicating the conflicting sections. The code between <<<<<<< HEAD and ======= is your change. The code between ======= and >>>>>>> [branch_name] is the incoming change. 4. Resolve Manually: Edit the file to include the correct code, combining or choosing between 'ours' and 'theirs'. 5. Add & Commit: Once resolved, git add <conflicted_file> and then git commit -m "Resolve merge conflict" to finalize. Understanding how to identify and resolve merge conflicts correctly is essential for maintaining code quality and avoiding accidental overwrites in collaborative DevOps environments. This visual simplifies the concept and helps beginners understand what’s actually happening behind the scenes. #Git #GitHub #DevOps #VersionControl #DevOpsLearning #TeamCollaboration #MultiCloudDevOps

I just came across this solid walkthrough on using LazyGit to streamline Git workflows - potentially a "Faster, Cleaner Way to Work with Git". For those who live in the terminal, LazyGit provides a lightweight TUI that reduces context switching while handling staging, branching, rebasing, cherry-picking, and conflict resolution, all without leaving the CLI. It doesn’t replace Git fundamentals; it accelerates them. In complex repos or multi-branch environments, reducing command friction and visualising state changes clearly can materially improve velocity and reduce errors. LazyGit works with GitHub, GitLab, Bitbucket, or any Git remote, because under the hood it’s still just Git. I am always keen to adopt tools that automate repetitive tasks or introduce efficient shortcuts into my development workflow (that includes GitHub, ChatGPT, Codex and Windsurf AI), this is definitely something I will experiment with. How to Use Lazygit to Improve Your Git Workflow https://lnkd.in/gFt7Hs9j #Git #DevTools #EngineeringProductivity #CLI #SoftwareDevelopment #Codex #WindsurfAI

🚀 Day 6 – Git & GitHub Series | Reverting & Resetting (Undo Like a Pro) Let’s be honest… Every developer has done this at least once: 👉 committed wrong code 👉 deleted a file by mistake 👉 pushed something broken 👉 or thought “How do I go back now?!” 😅 That’s where Git recovery commands save your life. Because in real projects, it’s not about never making mistakes — it’s about fixing them safely and fast. 🔹 Must-know Undo Commands ✅ Move HEAD but keep changes git reset --soft <commit_id> ✅ Unstage changes git reset --mixed <commit_id> ✅ Reset everything (⚠ dangerous) git reset --hard <commit_id> ✅ Safely undo via new commit (team-friendly) git revert <commit_id> ✅ Restore files git restore <file> ✅ Remove from staging git restore --staged <file> ✅ Clean unwanted files git clean -f git clean -fd 💡 Real-world rule I follow ✔ Working alone → reset ✔ Working in team/shared repo → revert ✔ Avoid --hard unless 100% sure ✔ Always double-check before cleaning Small knowledge → Huge time saved during production issues. 📌 This is Day 6 of my Git Mastery Series Daily practical Git + GitHub tips for Developers, DevOps & SREs. If you’re serious about leveling up your engineering skills: 👉 Follow for the next post #Git #GitHub #DevOps #SRE #VersionControl #SoftwareEngineering #Developers #ProgrammingLife #TechLearning #CloudComputing #Debugging #OpenSource #CareerGrowth #LearnInPublic

Day 12/100 – Git & GitHub Deep Dive: Restore, Reset & Force Push 🔁🐙 Today was all about fixing mistakes in Git the right way — something every developer & DevOps engineer faces in real projects. I learned how to safely undo changes, uncommit code, and even force push when local and remote histories don’t match. 🛠️ What I did today ✔ Cloned a GitHub repository ✔ Modified files in the working directory ✔ Checked file states using git status ✔ Used git restore to discard changes ✔ Used git restore --staged to unstage files ✔ Configured Git username & email ✔ Committed changes with proper messages ✔ Explored git reset (soft, mixed & hard) ✔ Understood commit history using git log ✔ Fixed wrong commits using reset ✔ Used force push to sync local & remote branch ✔ Learned how companies handle private repos & tokens 🔁 Git File Lifecycle Working Directory → Staging Area → Commit History → Remote Repository (GitHub) 🔄 Reset Types Explained Soft Reset → Removes commit → Keeps changes staged Mixed Reset → Removes commit → Keeps changes in working directory Hard Reset → Removes commit → Deletes changes completely (⚠️ careful) 🚀 Important Commands Used gitclone <repo-url> git status # Discard local changes git restore index.html # Unstage files git restore --staged index.html # Stage & commit git add . git commit -m"Updated index.html" # View history gitlog --oneline # Reset commits git reset --soft HEAD~1 git reset --mixed HEAD~1 git reset --hard HEAD~1 # Force push git push -f origin main 🔐 Private Repository Access ✔ Companies use private repositories ✔ Cloning requires Personal Access Token (PAT) ✔ Tokens are safer than passwords ✔ Token-based access is industry standard 💡 Key Learnings ✔ Git mistakes are normal — fixing them is a skill ✔ Restore helps discard unwanted changes ✔ Reset helps fix wrong commits ✔ Force push should be used carefully ✔ Understanding Git internals = confidence at work ✔ Essential knowledge for DevOps & real projects 📌 Save this post — Git reset & force push are frequently asked in interviews. #Git #GitHub #DevOps #VersionControl #SoftwareDevelopment #CloudCareers #Linux #100DaysOfDevOps #SRTechOps

🚀 Day 34 of #100DaysOfDevOps with #KodeKloud 🚀 Today's challenge was all about Git Hooks 🧠 Need to Know Git provides a way to trigger custom scripts when certain important actions occur. There are two types of hooks: client-side and server-side. 🔹 Client-side: triggered by operations such as committing and merging 🔹 Server-side: triggered by network operations such as receiving pushed commits To install a hook, you just need to rename it by removing .sample from its name in the .git/hooks directory The task was to create a post-update hook to generate a release tag for each push. The post-update hook runs right after a push is completed on the remote repository. Here's How I Did It: 🔹 Merged the feature and master branches in the repository 🔹 Went to the remote repository (/opt/ecommerce.git), accessed the Git hooks, and updated the post-update hook by removing .sample from its name and changing its content to: #!/bin/bash if [ "$1" = refs/heads/master ]; then echo "Creating release tag" git tag release-date '+%Y-%m-%d' master fi 🔹 Went back to the local repository and pushed the changes 🔹 Tested the release tag in the remote repository using git tag 🔹 Verified the tag release-2026-02-05 💡 Key Takeaways: ✅ Since this specific hook is a server-side one, the configuration and script must be in the remote repository, not the local one (took me a while to figure that out!). ✅ There are many other useful hooks as well, such as: 🔸pre-commit: runs first, before you even type a commit message. 🔸post-commit: runs after a commit is made. often used for notifications or similar tasks. 🔸 post-merge: runs after a successful merge. It can be used to restore data that Git doesn't track, such as file permissions. …and many others that perform specific tasks at different stages of the Git workflow. Have a good Day, everyone! 🦬 #GitHooks #DevOps #AutomationScripting

🚀 Git is easy (actually) — once you know these commands If Git feels scary, it’s usually because of too many concepts at once. In reality, most day-to-day work comes down to these commands 👇 🧱 Getting Started 🔹 git init — Start a new Git repository 🔹 git config — Set username & email 🔹 git clone — Copy an existing repo 🔹 git remote add origin — Set remote origin 📊 Daily Workflow 🔹 git status — Check what changed 🔹 git add — Stage files 🔹 git commit — Save your changes 🔹 git push — Send commits to remote 🔹 git pull — Get latest changes 🔹 git fetch — Download changes (no merge) 🌿 Branches & Collaboration 🔹 git branch — Create or list branches 🔹 git checkout — Switch branches 🔹 git merge — Merge branches 🔹 git rebase — Keep history clean 🔍 Tracking & Debugging 🔹 git log — View commit history 🔹 git diff — See what changed 🛟 Saving Yourself 🔹 git stash — Save work temporarily 🔹 git reset — Undo local commits 🔹 git revert — Safely undo a commit 🔹 git cherry-pick — Pick a specific commit 🔹 git squash — Combine multiple commits into one 💡 Learn these well, and Git suddenly feels… manageable 😄 You don’t need to know everything — just the right things. #Git #DevOps #VersionControl #SoftwareEngineering #Developers #Cloud #Automation Just the right ones. 🚀 #Git #DevOps #Developers #VersionControl #Cloud #Automation

𝑼𝒏𝒅𝒆𝒓 𝒕𝒉𝒆 𝑯𝒐𝒐𝒅: 𝑮𝒊𝒕 & 𝑩𝒊𝒕𝒃𝒖𝒄𝒌𝒆𝒕 — the clarity I wish I had earlier I spent almost 2 days trying to truly understand Git and Bitbucket. Not commands. Not diagrams. But what actually happens under the hood. Here’s the clarity that finally clicked — sharing it so someone else gets it in the first read. 🔹 1. 𝐓𝐡𝐞𝐫𝐞 𝐚𝐫𝐞 𝐓𝐖𝐎 𝐆𝐢𝐭 𝐫𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐢𝐞𝐬, 𝐧𝐨𝐭 𝐨𝐧𝐞 𝐋𝐨𝐜𝐚𝐥 𝐆𝐢𝐭 → on your laptop 𝐒𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞 𝐆𝐢𝐭 → on Bitbucket’s server 👉 Bitbucket does not replace Git 👉 Bitbucket wraps and exposes a server-side Git repository Git exists on both sides. 🔹 2. 𝐆𝐢𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐞𝐧𝐠𝐢𝐧𝐞. 𝐁𝐢𝐭𝐛𝐮𝐜𝐤𝐞𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐢𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞. 𝐆𝐢𝐭 𝐢𝐬 𝐫𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐥𝐞 𝐟𝐨𝐫: tracking file changes creating commits managing branches merging code 𝐁𝐢𝐭𝐛𝐮𝐜𝐤𝐞𝐭 𝐩𝐫𝐨𝐯𝐢𝐝𝐞𝐬: UI permissions Pull Requests code review & approvals 👉 All real work is done by Git 👉 Bitbucket adds visibility and control 🔹 3. 𝐂𝐨𝐦𝐦𝐢𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐬 𝐎𝐍𝐋𝐘 𝐢𝐧 𝐆𝐢𝐭 (𝐥𝐨𝐜𝐚𝐥𝐥𝐲) When you modify files → Git sees changes When you commit: Git saves a snapshot Git creates a commit ID This happens only in local Git Bitbucket has no role here 👉 Commits are Git objects, not Bitbucket actions 🔹 4. 𝐏𝐮𝐬𝐡 𝐜𝐨𝐩𝐢𝐞𝐬 𝐜𝐨𝐦𝐦𝐢𝐭𝐬 𝐭𝐨 𝐬𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞 𝐆𝐢𝐭 git push does NOT create new commits 𝐈𝐭 𝐜𝐨𝐩𝐢𝐞𝐬 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐜𝐨𝐦𝐦𝐢𝐭𝐬: from local Git to server-side Git (on Bitbucket) 👉 After push: Server-side Git already has updated files Changes exist in the feature branch Bitbucket UI just shows what Git already has. 🔹 5. 𝐅𝐞𝐭𝐜𝐡 𝐯𝐬 𝐏𝐮𝐥𝐥 (𝐢𝐦𝐩𝐨𝐫𝐭𝐚𝐧𝐭 𝐝𝐢𝐬𝐭𝐢𝐧𝐜𝐭𝐢𝐨𝐧) 𝐅𝐞𝐭𝐜𝐡: Downloads information from server Git Does NOT change your files 𝐏𝐮𝐥𝐥: Fetch + merge Updates your local files 👉 Both are Git operations, not Bitbucket logic. 🔹 6. 𝐏𝐮𝐥𝐥 𝐑𝐞𝐪𝐮𝐞𝐬𝐭 𝐢𝐬 𝐍𝐎𝐓 𝐆𝐢𝐭 𝐏𝐮𝐥𝐥 𝐑𝐞𝐪𝐮𝐞𝐬𝐭 (𝐏𝐑): belongs to Bitbucket is for comparison, review, and approval 𝐏𝐑: does NOT create commits does NOT change code does NOT copy files 👉 PR is a decision layer, not an execution layer 🔹 7. 𝐌𝐞𝐫𝐠𝐞 𝐢𝐬 𝐰𝐡𝐞𝐫𝐞 𝐜𝐨𝐝𝐞 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐦𝐨𝐯𝐞𝐬 𝐛𝐫𝐚𝐧𝐜𝐡𝐞𝐬 When PR is approved and merged: Bitbucket UI triggers the action Git performs the merge Feature branch commits are applied to target branch (main/develop) 👉 Merge is Git’s job 👉 PR only controls when merge is allowed #git #bitbucket

My GIT - Cheat sheet 𝐏𝐫𝐨 𝐭𝐢𝐩 - To learn Git better, ditch the GUI and use the command line. 𝐖𝐡𝐚𝐭? A distributed version control system that tracks changes in files over time. 𝐖𝐡𝐲? Enables collaboration, branching, merging and a complete project history. 📌 𝐊𝐞𝐲 𝐓𝐞𝐫𝐦𝐢𝐧𝐨𝐥𝐨𝐠𝐢𝐞𝐬 - ◾ Repository A directory containing your project's complete history. ◾ Working Directory The current state of your project files. ◾ Staging Area (Index) Where you prepare changes for the next commit. ◾ Commit A snapshot of your project at a specific point in time. ◾ Branch A separate line of development. Remote: A version of your repository hosted on a server (e.g., GitHub, GitLab). 📌 𝐆𝐢𝐭 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 [1.] Commit Early, Commit Often ◾ Don't let changes pile up. ◾ Commit frequently to create smaller, more manageable snapshots of your work. ◾ This makes it easier to track progress, identify issues and revert if needed. [2.] One Change per Commit ◾ Keep your commits focused on a single logical change or feature. ◾ This improves readability and makes it easier to isolate and revert specific changes. [3.] Clear Commit Messages ◾ Write concise yet descriptive commit messages that explain what you changed and why. ◾ This makes it easier for you and your collaborators to understand the purpose of each commit in the future. ◾ Include some change or ticket # [4.] Merge or Rebase ◾ Use git merge to combine branches, or git rebase to apply your changes on top of another branch. ◾ Choose the method that best suits your workflow and preferences. [5.] Delete Merged Branches ◾ Once a branch has been merged, delete it to keep your repository tidy and avoid confusion. [6.] Pull Regularly ◾ Always fetch and merge the latest changes from the remote repository before starting new work. ◾ This helps avoid conflicts and keeps your local repository in sync with your team. [7.] Code Reviews ◾ Use pull requests or similar mechanisms to get feedback on your changes before merging them into the main branch. ◾ Code reviews help catch errors, improve code quality and ensure consistency across the codebase. [8.] Resolve Conflicts Carefully ◾ If conflicts arise when merging branches, resolve them carefully and thoroughly. ◾ Test your changes after resolving conflicts to ensure everything works as expected. git commit -m "works on my machine" 🙂 Follow Mayank for more such insights.