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
Git Best Practices for Senior Engineers: Rebase, Cherry-pick, Amend and More
More Relevant Posts
-
Here’s a powerful list of 50+ Git commands every developer should already be using. ========================================= # 🔹 Repository Setup git init # Initialize new repo git clone <url> # Clone remote repo # 🔹 Basic Workflow git status # Check current state git add <file> # Stage specific file git add . # Stage all changes git commit -m "message" # Commit changes git commit -am "message" # Stage + commit tracked files git commit --amend # Edit last commit # 🔹 History git log # Full commit history git log --oneline # Compact history git log --stat # History with stats git show <commit_id> # Show commit details # 🔹 Branching git branch # List branches git branch <name> # Create branch git branch -d <name> # Delete branch git branch -m <new_name> # Rename branch # 🔹 Switching git checkout <branch> # Switch branch git checkout -b <branch> # Create + switch git checkout <commit_id> # Checkout commit git switch <branch> # Modern switch git switch -c <branch> # Create + switch # 🔹 Merging & Rebase git merge <branch> # Merge branch git merge --no-ff <branch> # Force merge commit git rebase <branch> # Rebase branch git rebase -i HEAD~n # Interactive rebase git cherry-pick <commit_id> # Apply specific commit # 🔹 Remote git remote -v # List remotes git remote add origin <url> # Add remote git push origin <branch> # Push to remote git push -u origin <branch> # Set upstream git push --force # Force push (careful ⚠️) git pull # Fetch + merge git fetch # Fetch only git branch --set-upstream-to=origin/<branch> # 🔹 Undo / Reset git reset HEAD~1 # Undo last commit (keep changes) git reset --soft HEAD~1 # Undo + keep staged git reset --hard HEAD~1 # Reset everything git revert <commit_id> # Safe undo commit # 🔹 File Changes git restore <file> # Discard changes git clean -fd # Remove untracked files git diff # Unstaged changes git diff --staged # Staged changes git diff <branch1> <branch2> # Compare branches # 🔹 Insights git blame <file> # Who changed what git shortlog # Summary by author # 🔹 Stash git stash # Save changes git stash pop # Apply + remove stash git stash list # List stashes git stash apply stash@{n} # Apply specific stash git stash drop # Delete stash git stash clear # Clear all # 🔹 Config git config --global user.name "Your Name" git config --global user.email "your@email.com" # 🔹 Shortcuts & Help git alias # Create shortcuts git help # Open docs #git #github
To view or add a comment, sign in
-
-
Git commands I used 99% of the time being a Software Engineer for 3+ years with working flow: 𝟭. 𝗴𝗶𝘁 𝗱𝗶𝗳𝗳: Show file differences not yet staged. 𝟮. 𝗴𝗶𝘁 𝗰𝗼𝗺𝗺𝗶𝘁 -𝗮 -𝗺 "𝗰𝗼𝗺𝗺𝗶𝘁 𝗺𝗲𝘀𝘀𝗮𝗴𝗲": Commit all tracked changes with a message. 𝟯. 𝗴𝗶𝘁 𝘀𝘁𝗮𝘁𝘂𝘀: Show the state of your working directory. 𝟰. 𝗴𝗶𝘁 𝗮𝗱𝗱 𝗳𝗶𝗹𝗲_𝗽𝗮𝘁𝗵:Add file(s) to the staging area. 𝟱. 𝗴𝗶𝘁 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 -𝗯 𝗯𝗿𝗮𝗻𝗰𝗵_𝗻𝗮𝗺𝗲: Create and switch to a new branch. 𝟲. 𝗴𝗶𝘁 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 𝗯𝗿𝗮𝗻𝗰𝗵_𝗻𝗮𝗺𝗲: Switch to an existing branch. 𝟳. 𝗴𝗶𝘁 𝗰𝗼𝗺𝗺𝗶𝘁 --𝗮𝗺𝗲𝗻𝗱:Modify the last commit. 𝟴. 𝗴𝗶𝘁 𝗽𝘂𝘀𝗵 𝗼𝗿𝗶𝗴𝗶𝗻 𝗯𝗿𝗮𝗻𝗰𝗵_𝗻𝗮𝗺𝗲: Push a branch to a remote. 𝟵. 𝗴𝗶𝘁 𝗽𝘂𝗹𝗹: Fetch and merge remote changes. 𝟭𝟬. 𝗴𝗶𝘁 𝗿𝗲𝗯𝗮𝘀𝗲 -𝗶: Rebase interactively, rewrite commit history. 𝟭𝟭. 𝗴𝗶𝘁 𝗰𝗹𝗼𝗻𝗲: Create a local copy of a remote repo. 𝟭𝟮. 𝗴𝗶𝘁 𝗺𝗲𝗿𝗴𝗲: Merge branches together. 𝟭𝟯. 𝗴𝗶𝘁 𝗹𝗼𝗴 --𝘀𝘁𝗮𝘁: Show commit logs with stats. 𝟭𝟰. 𝗴𝗶𝘁 𝘀𝘁𝗮𝘀𝗵: Stash changes for later. 𝟭𝟱. 𝗴𝗶𝘁 𝘀𝘁𝗮𝘀𝗵 𝗽𝗼𝗽: Apply and remove stashed changes. 𝟭𝟲. 𝗴𝗶𝘁 𝘀𝗵𝗼𝘄 𝗰𝗼𝗺𝗺𝗶𝘁_𝗶𝗱: Show details about a commit. 𝟭𝟳. 𝗴𝗶𝘁 𝗿𝗲𝘀𝗲𝘁 𝗛𝗘𝗔𝗗~𝟭: Undo the last commit, preserving changes locally. 𝟭𝟴. 𝗴𝗶𝘁 𝗳𝗼𝗿𝗺𝗮𝘁-𝗽𝗮𝘁𝗰𝗵 -𝟭 𝗰𝗼𝗺𝗺𝗶𝘁_𝗶𝗱: Create a patch file for a specific commit. 𝟭𝟵. 𝗴𝗶𝘁 𝗮𝗽𝗽𝗹𝘆 𝗽𝗮𝘁𝗰𝗵_𝗳𝗶𝗹𝗲_𝗻𝗮𝗺𝗲: Apply changes from a patch file. 𝟮𝟬. 𝗴𝗶𝘁 𝗯𝗿𝗮𝗻𝗰𝗵 -𝗗 𝗯𝗿𝗮𝗻𝗰𝗵_𝗻𝗮𝗺𝗲: Delete a branch forcefully. 𝟮𝟭. 𝗴𝗶𝘁 𝗿𝗲𝘀𝗲𝘁: Undo commits by moving branch reference. 𝟮𝟮. 𝗴𝗶𝘁 𝗿𝗲𝘃𝗲𝗿𝘁: Undo commits by creating a new commit. 𝟮𝟯. 𝗴𝗶𝘁 𝗰𝗵𝗲𝗿𝗿𝘆-𝗽𝗶𝗰𝗸 𝗰𝗼𝗺𝗺𝗶𝘁_𝗶𝗱: Apply changes from a specific commit. 𝟮𝟰. 𝗴𝗶𝘁 𝗯𝗿𝗮𝗻𝗰𝗵: Lists branches. 𝟮𝟱. 𝗴𝗶𝘁 𝗿𝗲𝘀𝗲𝘁 --𝗵𝗮𝗿𝗱: Resets everything to a previous commit, erasing all uncommitted changes. <~~~~~~#𝑷𝒍𝒂𝒚𝒘𝒓𝒊𝒈𝒉𝒕 #𝑻𝒆𝒔𝒕𝒊𝒏𝒈~~~~~~> 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭 𝐀𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐨𝐧 𝐓𝐫𝐚𝐢𝐧𝐢𝐧𝐠 | 𝐉𝐒 & 𝐓𝐒 𝐅𝐫𝐨𝐦 𝐙𝐞𝐫𝐨 𝐭𝐨 𝐒𝐃𝐄𝐓-𝐑𝐞𝐚𝐝𝐲 𝐅𝐑𝐄𝐄 𝐓𝐫𝐚𝐢𝐧𝐞𝐫 𝐒𝐞𝐬𝐬𝐢𝐨𝐧 — 𝟐𝟒𝐭𝐡 𝐀𝐩𝐫𝐢𝐥 𝟐𝟎𝟐𝟔 𝐉𝐨𝐢𝐧 𝐖𝐡𝐚𝐭𝐬𝐀𝐩𝐩 𝐟𝐨𝐫 𝐝𝐞𝐦𝐨 𝐝𝐞𝐭𝐚𝐢𝐥𝐬: https://lnkd.in/dqu3baKJ 𝐇𝐚𝐩𝐩𝐲 𝐓𝐞𝐬𝐭𝐢𝐧𝐠! 𝐅𝐨𝐥𝐥𝐨𝐰 𝐦𝐲 𝐜𝐡𝐚𝐧𝐧𝐞𝐥𝐬 - 📲 WhatsApp :https://lnkd.in/dYMtyi_K 📢 Telegram :https://lnkd.in/dmT_T-mY ✨️ Instagram :https://lnkd.in/gbsyFSc4
To view or add a comment, sign in
-
-
Approving a Pull Request without running the tests locally is the software engineering equivalent of closing your eyes and crossing a busy street. 🙈🚦 When I was building the early versions of the Railway Management System, we had a strict rule: "Don't break the main branch." But developers are human. You write a brilliant new feature for seat reservations, forget to run mvn clean test, hit "Merge," and suddenly the entire booking API is throwing 500 Internal Server Error for everyone. That’s when I stopped trusting humans and started trusting GitHub Actions. If you want to keep your codebase stable, your repository needs a bouncer. Here is the exact anatomy of the pr-check.yml workflow I write to automate testing on every single pull request: 🎯 1. The Interceptor (on: pull_request): This workflow sleeps until someone tries to merge code into the main branch. The moment a PR is opened, the Action wakes up and intercepts the code before it can do any damage. ☕ 2. The Backend Validator (actions/setup-java): It spins up a fresh Ubuntu container, installs the exact version of Java my Spring Boot app needs, and automatically runs my JUnit test suite. If my new payment logic accidentally breaks an existing booking test, the Action fails, and the PR turns a glaring, angry red. 🔴 ⚛️ 3. The Frontend Sibling (actions/setup-node): Because I'm running a full-stack repo, I run a parallel job for React. It installs Node.js, runs npm ci, and executes the frontend tests. It guarantees that the UI components are perfectly in sync with the backend changes. 🔒 4. The Ultimate Safety Net (Branch Protection): Writing the script isn't enough. I go into the GitHub repository settings and activate "Require status checks to pass before merging." This is the real magic. Even as the repo owner, I physically cannot click the green "Merge" button until the GitHub Action finishes running and passes every single test. Stop wasting your code review time checking for broken tests or syntax errors. Let the robots do the grunt work so you can focus on reviewing the actual architecture. What is your favorite CI/CD tool right now? Are you writing GitHub Actions, or are you on GitLab CI / Bitbucket Pipelines? Let’s chat below! 👇 Follow RAHUL VIJAYAN for more. #GitHubActions #DevOps #CICD #SpringBoot #ReactJS #BackendEngineering #SoftwareDevelopment #TechCareers
To view or add a comment, sign in
-
-
𝗧𝗵𝗮𝘁 "𝗪𝗵𝗮𝘁 𝗱𝗶𝗱 𝗜 𝗲𝘃𝗲𝗻 𝗱𝗼 𝗵𝗲𝗿𝗲?" 𝗳𝗲𝗲𝗹𝗶𝗻𝗴 𝘄𝗵𝗲𝗻 𝗹𝗼𝗼𝗸𝗶𝗻𝗴 𝗮𝘁 𝗼𝗹𝗱 𝗰𝗼𝗺𝗺𝗶𝘁𝘀 𝗶𝘀 𝘁𝗵𝗲 𝘄𝗼𝗿𝘀𝘁. 🤦♂️ 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
To view or add a comment, sign in
-
-
🧠 TIL: git update-index --skip-worktree - a tiny git flag that made my dev loop so much cleaner. Every project has those files - the ones that are tracked in the repo, but you need to tweak locally just to get a sane dev experience. For me today, it was two BullMQ processor files that spin up cron jobs (heartbeats, cache clearers) on every boot. Great in staging/prod. Annoying as heck when I'm just trying to debug something unrelated on my laptop. The catch: they're tracked files. So .gitignore doesn't help. .git/info/exclude doesn't help. The moment I comment out a scheduler to quiet things down, my git status lights up - and one stray git add . away from shipping a broken commit. The usual workaround is stash / pop - and it's genuinely painful: Before every branch switch → git stash After switching → git stash pop Forget once → you lose your local tweaks or hit merge conflicts on your own stash Multiple local tweaks across multiple files = a growing stash stack you have to babysit git status still nags you until you stash And good luck if you want to commit other changes without accidentally including these One line fixes all of that: git update-index --skip-worktree path/to/file Now git pretends the file matches the index. No more noise in status, no accidental add, no stash dance. Your local edits just… stay local. Forever. Silently. Undo is equally simple, whenever you want: git update-index --no-skip-worktree path/to/file One caveat worth knowing: if upstream ever changes that file, you'll need to --no-skip-worktree, stash, pull, and re-flag. But for files that rarely change upstream, it's a massive quality-of-life win. If you've ever muttered "why is this file showing up in my diff AGAIN" - give this a try. 🙌 Found this via this great little writeup: https://lnkd.in/g_JqgPG7 #git #developerproductivity #softwareengineering #TIL
To view or add a comment, sign in
-
Master Git with These Essential Commands! 🖥️ 1. Basic Git Commands 📌 git init – Initialize a Git repository. 📌 git clone <repo_url> – Clone a repository to your local machine. 📌 git status – Check the current state of your repository. 📌 git add <file> – Stage changes for commit. 📌 git commit -m "message" – Save changes with a commit message. 📌 git push – Upload local commits to a remote repository. 📌 git pull – Download and merge changes from a remote repository. 2. Branching & Merging 📌 git branch – List branches. 📌 git branch <branch_name> – Create a new branch. 📌 git checkout <branch_name> – Switch to another branch. 📌 git checkout -b <branch_name> – Create and switch to a new branch. 📌 git merge <branch_name> – Merge changes from another branch. 3. Remote Repository Management 📌 git remote -v – View remote repositories. 📌 git remote add <name> <url> – Add a remote repository. 📌 git push origin <branch> – Push changes to a remote branch. 📌 git pull origin <branch> – Pull changes from a remote branch. 4. Viewing & Comparing Changes 📌 git log – View commit history. 📌 git log --oneline – View a simplified commit history. 📌 git diff – Show changes between commits or branches. 📌 git blame <file> – Show who changed each line of a file. 5. Undoing Changes & Resetting 📌 git reset --soft HEAD~1 – Undo last commit but keep changes staged. 📌 git reset --hard HEAD~1 – Undo last commit and remove changes. 📌 git revert <commit_id> – Revert changes without losing history. 📌 git restore <file> – Undo changes in a file. 6. Stashing Changes 📌 git stash – Temporarily save changes without committing. 📌 git stash list – View saved stashes. 📌 git stash pop – Apply the last stash and remove it. 7. Tags & Releases 📌 git tag <tag_name> – Create a tag for a specific commit. 📌 git tag -a <tag_name> -m "message" – Annotated tag with description. 📌 git push origin --tags – Push all tags to the remote repository. 8. Git Hooks & Automation 📌 git pre-commit – Runs scripts before a commit. 📌 git post-commit – Runs scripts after a commit. 📌 git pre-push – Runs checks before pushing to remote. 9. Handling Merge Conflicts 📌 git mergetool – Open a merge conflict resolution tool. 📌 git merge --abort – Cancel a merge. 📌 git diff <branch_1> <branch_2> – Compare differences between branches. 10. Git & DevOps 📌 git fetch --all – Fetch changes from all remotes. 📌 git rebase <branch> – Reapply commits on top of another branch. 📌 git cherry-pick <commit_id> – Apply a specific commit from another branch. 𝐒𝐞𝐥𝐞𝐧𝐢𝐮𝐦-𝐉𝐚𝐯𝐚 & 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭-𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭 𝐓𝐫𝐚𝐢𝐧𝐢𝐧𝐠 𝐒𝐭𝐚𝐫𝐭𝐬 𝐨𝐧 𝟐𝟎𝐭𝐡 𝐀𝐩𝐫𝐢𝐥 𝟐𝟎𝟐𝟔! 𝐑𝐞𝐠𝐢𝐬𝐭𝐞𝐫 𝐧𝐨𝐰 𝐟𝐨𝐫 𝐟𝐫𝐞𝐞 𝐝𝐞𝐦𝐨 𝐜𝐥𝐚𝐬𝐬𝐞𝐬:https://lnkd.in/gvbgraRa Follow Sripathi Teja for more helpful content. #GitCommands #OpenSource #GitWorkflow
To view or add a comment, sign in
-
Master Git with These Essential Commands! 🖥️ 1. Basic Git Commands 📌 git init – Initialize a Git repository. 📌 git clone <repo_url> – Clone a repository to your local machine. 📌 git status – Check the current state of your repository. 📌 git add <file> – Stage changes for commit. 📌 git commit -m "message" – Save changes with a commit message. 📌 git push – Upload local commits to a remote repository. 📌 git pull – Download and merge changes from a remote repository. 2. Branching & Merging 📌 git branch – List branches. 📌 git branch <branch_name> – Create a new branch. 📌 git checkout <branch_name> – Switch to another branch. 📌 git checkout -b <branch_name> – Create and switch to a new branch. 📌 git merge <branch_name> – Merge changes from another branch. 3. Remote Repository Management 📌 git remote -v – View remote repositories. 📌 git remote add <name> <url> – Add a remote repository. 📌 git push origin <branch> – Push changes to a remote branch. 📌 git pull origin <branch> – Pull changes from a remote branch. 4. Viewing & Comparing Changes 📌 git log – View commit history. 📌 git log --oneline – View a simplified commit history. 📌 git diff – Show changes between commits or branches. 📌 git blame <file> – Show who changed each line of a file. 5. Undoing Changes & Resetting 📌 git reset --soft HEAD~1 – Undo last commit but keep changes staged. 📌 git reset --hard HEAD~1 – Undo last commit and remove changes. 📌 git revert <commit_id> – Revert changes without losing history. 📌 git restore <file> – Undo changes in a file. 6. Stashing Changes 📌 git stash – Temporarily save changes without committing. 📌 git stash list – View saved stashes. 📌 git stash pop – Apply the last stash and remove it. 7. Tags & Releases 📌 git tag <tag_name> – Create a tag for a specific commit. 📌 git tag -a <tag_name> -m "message" – Annotated tag with description. 📌 git push origin --tags – Push all tags to the remote repository. 8. Git Hooks & Automation 📌 git pre-commit – Runs scripts before a commit. 📌 git post-commit – Runs scripts after a commit. 📌 git pre-push – Runs checks before pushing to remote. 9. Handling Merge Conflicts 📌 git mergetool – Open a merge conflict resolution tool. 📌 git merge --abort – Cancel a merge. 📌 git diff <branch_1> <branch_2> – Compare differences between branches. 10. Git & DevOps 📌 git fetch --all – Fetch changes from all remotes. 📌 git rebase <branch> – Reapply commits on top of another branch. 📌 git cherry-pick <commit_id> – Apply a specific commit from another branch.
To view or add a comment, sign in
-
Master Git with These Essential Commands! 🖥️ 1. Basic Git Commands 📌 git init – Initialize a Git repository. 📌 git clone <repo_url> – Clone a repository to your local machine. 📌 git status – Check the current state of your repository. 📌 git add <file> – Stage changes for commit. 📌 git commit -m "message" – Save changes with a commit message. 📌 git push – Upload local commits to a remote repository. 📌 git pull – Download and merge changes from a remote repository. 2. Branching & Merging 📌 git branch – List branches. 📌 git branch <branch_name> – Create a new branch. 📌 git checkout <branch_name> – Switch to another branch. 📌 git checkout -b <branch_name> – Create and switch to a new branch. 📌 git merge <branch_name> – Merge changes from another branch. 3. Remote Repository Management 📌 git remote -v – View remote repositories. 📌 git remote add <name> <url> – Add a remote repository. 📌 git push origin <branch> – Push changes to a remote branch. 📌 git pull origin <branch> – Pull changes from a remote branch. 4. Viewing & Comparing Changes 📌 git log – View commit history. 📌 git log --oneline – View a simplified commit history. 📌 git diff – Show changes between commits or branches. 📌 git blame <file> – Show who changed each line of a file. 5. Undoing Changes & Resetting 📌 git reset --soft HEAD~1 – Undo last commit but keep changes staged. 📌 git reset --hard HEAD~1 – Undo last commit and remove changes. 📌 git revert <commit_id> – Revert changes without losing history. 📌 git restore <file> – Undo changes in a file. 6. Stashing Changes 📌 git stash – Temporarily save changes without committing. 📌 git stash list – View saved stashes. 📌 git stash pop – Apply the last stash and remove it. 7. Tags & Releases 📌 git tag <tag_name> – Create a tag for a specific commit. 📌 git tag -a <tag_name> -m "message" – Annotated tag with description. 📌 git push origin --tags – Push all tags to the remote repository. 8. Git Hooks & Automation 📌 git pre-commit – Runs scripts before a commit. 📌 git post-commit – Runs scripts after a commit. 📌 git pre-push – Runs checks before pushing to remote. 9. Handling Merge Conflicts 📌 git mergetool – Open a merge conflict resolution tool. 📌 git merge --abort – Cancel a merge. 📌 git diff <branch_1> <branch_2> – Compare differences between branches. 10. Git & DevOps 📌 git fetch --all – Fetch changes from all remotes. 📌 git rebase <branch> – Reapply commits on top of another branch. 𝑷𝒍𝒂𝒚𝒘𝒓𝒊𝒈𝒉𝒕 𝒘𝒊𝒕𝒉 𝑱𝒂𝒗𝒂𝑺𝒄𝒓𝒊𝒑𝒕& 𝑻𝒚𝒑𝒆𝑺𝒄𝒓𝒊𝒑𝒕 ( 𝑨𝑰 𝒊𝒏 𝑻𝒆𝒔𝒕𝒊𝒏𝒈, 𝑮𝒆𝒏𝑨𝑰, 𝑷𝒓𝒐𝒎𝒑𝒕 𝑬𝒏𝒈𝒊𝒏𝒆𝒆𝒓𝒊𝒏𝒈)—𝑻𝒓𝒂𝒊𝒏𝒊𝒏𝒈 𝑺𝒕𝒂𝒓𝒕𝒔 𝒇𝒓𝒐𝒎 20𝒕𝒉 𝑨𝒑𝒓𝒊𝒍 𝑹𝒆𝒈𝒊𝒔𝒕𝒆𝒓 𝒏𝒐𝒘 𝒕𝒐 𝒂𝒕𝒕𝒆𝒏𝒅 𝑭𝒓𝒆𝒆 𝑫𝒆𝒎𝒐: https://lnkd.in/dR3gr3-4 𝑶𝑹 𝑱𝒐𝒊𝒏 𝒕𝒉𝒆 𝑾𝒉𝒂𝒕𝒔𝑨𝒑𝒑 𝒈𝒓𝒐𝒖𝒑 𝒇𝒐𝒓 𝒕𝒉𝒆 𝒍𝒂𝒕𝒆𝒔𝒕 𝑼𝒑𝒅𝒂𝒕𝒆: https://lnkd.in/ddHf2hdv #GitCommands #OpenSource #GitWorkflow
To view or add a comment, sign in
-
We’ve spent the last few sessions deconstructing the most powerful tool in the modern developer’s arsenal: 𝗚𝗶𝘁. 🛠️ It’s easy to view Git as just a series of commands to memorize. But as we’ve explored, Git is actually a sophisticated architectural framework designed to handle the complexity of human collaboration at scale. As 𝗟𝗶𝗻𝘂𝘀 𝗧𝗼𝗿𝘃𝗮𝗹𝗱𝘀, the creator of Git, famously put it: "Git is a content-addressable filesystem. It’s not just about tracking files; it’s about managing snapshots of reality." 🛰️ 𝗧𝗵𝗲 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 𝗦𝗼 𝗙𝗮𝗿: 𝗔 𝟳-𝗣𝗼𝘀𝘁 𝗥𝗲𝘁𝗿𝗼𝘀𝗽𝗲𝗰𝘁𝗶𝘃𝗲 If you’ve missed any of our deep dives, here is the "compressed" version of the architecture we’ve covered: • 𝗧𝗵𝗲 𝗙𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻: We moved past the "v2_final_final" era of local backups into the distributed paradigm where every machine holds the full project history. • 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 & 𝗖𝗼𝗻𝗳𝗶𝗴: We learned that professional Git starts with a verified identity—System, Global, and Local—ensuring every commit is a traceable digital signature. • 𝗧𝗵𝗲 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆 𝗔𝗻𝗮𝘁𝗼𝗺𝘆: We peeked under the hood of the .𝗴𝗶𝘁 directory to find the HEAD pointer, light-weight branches, and immutable snapshots. • 𝗧𝗵𝗲 𝗧𝗵𝗿𝗲𝗲-𝗧𝗿𝗲𝗲 𝗟𝗶𝗳𝗲𝗰𝘆𝗰𝗹𝗲: We mastered the "Buffer Zone" (Staging Area), learning why an intentional 𝗴𝗶𝘁 𝗮𝗱𝗱 is the key to atomic, logical commits. • 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹 𝗥𝗲𝗮𝗹𝗶𝘁𝗶𝗲𝘀: We explored how branches allow for safe experimentation and isolated hotfixes without ever disrupting the stable 𝗺𝗮𝗶𝗻 trunk. • 𝗧𝗵𝗲 𝗔𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗠𝗲𝗿𝗴𝗲: We reframed "Merge Conflicts" not as errors, but as healthy signals of parallel collaboration that can be resolved with surgical precision. • 𝗧𝗵𝗲 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝗘𝗻𝗴𝗶𝗻𝗲: Finally, we bridged the gap between local nodes and remote hubs (GitHub/GitLab), mastering the 𝗳𝗲𝘁𝗰𝗵-𝗿𝗲𝘃𝗶𝗲𝘄-𝗽𝘂𝗹𝗹-𝗽𝘂𝘀𝗵 workflow. 🚀 𝗪𝗵𝗮𝘁’𝘀 𝗡𝗲𝘅𝘁? We aren't finished yet. While we’ve mastered the "how" and "where" of Git, we still need to cover the advanced strategies that separate the seniors from the juniors. 𝗧𝗵𝗲 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗮𝘁𝗶𝗼𝗻 𝘄𝗶𝗹𝗹 𝗳𝗼𝗹𝗹𝗼𝘄 𝗶𝗻 𝗺𝘆 𝘂𝗽𝗰𝗼𝗺𝗶𝗻𝗴 𝗽𝗼𝘀𝘁𝘀, where we will dive into: 1. 𝗥𝗲𝗯𝗮𝘀𝗲 𝘃𝘀. 𝗠𝗲𝗿𝗴𝗲: The battle for the cleanest history. 2. 𝗦𝘁𝗮𝘀𝗵𝗶𝗻𝗴 & 𝗧𝗮𝗴𝗴𝗶𝗻𝗴: Managing temporary work and official releases. 3. 𝗚𝗶𝘁 𝗛𝗼𝗼𝗸𝘀 & 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻: Making the tool work for you while you sleep. 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Git isn't just a tool you use; it’s a language you speak. When you understand the architecture, you don't just write code—you engineer history. 𝗪𝗵𝗶𝗰𝗵 𝗼𝗳 𝘁𝗵𝗲𝘀𝗲 𝟳 𝗳𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝘁𝗼𝗽𝗶𝗰𝘀 𝘄𝗮𝘀 𝘁𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 "𝗮𝗵𝗮!" 𝗺𝗼𝗺𝗲𝗻𝘁 𝗳𝗼𝗿 𝘆𝗼𝘂? 𝗟𝗲𝘁'𝘀 𝗱𝗶𝘀𝗰𝘂𝘀𝘀 𝗯𝗲𝗹𝗼𝘄. 👇 #Git #SoftwareEngineering #DevOps #TechRecap #WebDevelopment #Programming #EngineeringExcellence
To view or add a comment, sign in
-
-
🚨 I was doing git pull origin dev on my feature branch for months... and I had NO idea I was doing it wrong. Let me save you from the same mistake. 👇 Here's the scenario most developers face daily — ✅ You are working on → login_api_integration branch ✅ Your teammate is working on → forgot_password_ui branch ✅ There is a common → dev branch Now dev has new updates and you want your feature branch to be up to date. What do most beginners do? (I did this too 😅) ❌ git pull origin dev Looks harmless right? But here's what actually happens internally — git fetch origin dev git merge origin/dev ← THIS is the problem It physically brings dev's commits INSIDE your feature branch. Your branch gets polluted with other people's code. Your PR becomes noisy with unnecessary merge commits. ✅ What you should actually do — git fetch origin git rebase origin/dev Think of it this way 👇 git merge = You copy all of dev's stuff into your room. Now your room has YOUR stuff + dev's stuff mixed together. 😵 git rebase = You just shift your room to the latest floor of the building. Your room still has ONLY your stuff, just placed on the latest foundation. 🏗️ Rebase does NOT bring dev's commits inside your branch. It just moves your starting point to the latest dev. Your branch stays clean with ONLY your own commits. ⚠️ But should you rebase every single time? NO. Rebase is a tool, not a ritual. Here's when to use it and when to skip it — ✅ Rebase WHEN — → Dev has new commits that affect your work → You are about to raise a PR → You want to clean up messy commits before code review ❌ Skip rebase WHEN — → Dev has no new commits since your last rebase → A teammate is also working on your same feature branch → Conflicts are too complex — a single clean merge may be better Simple rule before rebasing — Did dev get new commits? → Rebase About to raise a PR? → Rebase Teammate on same branch? → Don't rebase, use merge Dev unchanged since last rebase? → Skip it 🔑 Golden Rule — Always use rebase on your own feature branches. Never rebase shared branches like dev or main. If this helped you, share it with your team 🙌 Drop a comment if you were also doing git pull origin dev 😄 #Git #VersionControl #WebDevelopment #Programming #DevTips #SoftwareEngineering #CleanCode #TechLearning #DevCommunity #DevTips
To view or add a comment, sign in
-
Explore related topics
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development