Master 12 Essential Git Commands for Developers

🛠 Git in a Nutshell: The Map You Wish You Had from Day 1 Yesterday, we talked about the classic Rebase vs. Merge debate. But Git is so much more than just that one decision. If you are new to development or just want to solidify your fundamentals, here is the entire Git ecosystem broken down into 4 simple layers. 1. The States (The Foundation) Every file lives in one of these 4 states: · Untracked: Git doesn’t know this file exists yet. · Modified: You changed the file, but haven’t saved it to the database yet. · Staged: You used git add to mark what you want to save. · Committed: The data is safely stored in your local repository. 2. The Areas (The Environment) Think of these as the "rooms" where your code lives: · Working Directory: Where you mess things up. (Your local files) · Staging Index: The "holding zone." You prepare your commits here. · Repository (.git): The vault. Contains every snapshot of your project forever. 3. The References (The Navigation) · HEAD: The pointer that tells you where you are right now. · Tags: Permanent bookmarks (usually for releases like v1.0). · Branches: Movable pointers. The most important concept for collaboration. 4. The Key Operations (The Workflow) 📥 Local Flow: · git add → Move changes from Working Dir → Staging. · git commit → Move changes from Staging → Repository (creating a snapshot). 🌐 Collaboration Flow: · Fetch: Look at what changed in the remote repo without applying it. · Pull: Fetch + Merge (brings the remote changes to your local branch). · Push: Send your local commits to the remote server. 🚀 Advanced Essentials (The "Pro" Moves): · Rebase: Re-write history to keep a linear, clean project timeline. (Use this for feature branches before merging). · Cherry-pick: Take one specific commit from one branch and apply it to another. · Interactive Rebase (rebase -i): Squash messy commits, reword messages, or drop mistakes before pushing to the main branch. · Reflog: The emergency exit. If you think you lost code, git reflog shows you everywhere your HEAD has been. It’s the undo button for Git. The Golden Rule: Never rebase public branches. If someone else has pulled your branch, do not rewrite its history. Merge for public history, Rebase for private cleanup. #Git #GitHub #GitVisualization #Devops #AzureDevOps #VersionControl #GitOps #GitHubActions

Multiple Branches, One Repository Today I want to share a tool that transformed my Git workflow, especially when dealing with multiple simultaneous tasks: git worktree. If you, like me, have found yourself deep in a complex feature development when suddenly a critical bug arises on the main branch that requires an immediate hotfix, you know the pain. The common solutions are using git stash, making an incomplete "WIP" commit, or worst, cloning the entire repository again into another folder. git worktree solves this elegantly and natively. What is Git Worktree? Simply put, git worktree allows you to have multiple working copies (worktrees) associated with a single local Git repository (.git). Each worktree resides in a separate directory and can point to a different branch. This means you can have your feature/new-ui, bugfix/login, and main branches open and active at the same time, each in its own workspace. How I Use It (And Why You Should Too): 1. Parallel Development and Fewer Interruptions: Imagine I am working on the left worktree (branch feature/login). A call comes for an urgent hotfix. Instead of clearing my workspace with git stash, I simply open a new terminal and execute: git worktree add ../bugfix-checkout bugfix/checkout This creates a new folder bugfix-checkout (one level above my current repo) already checked out to the bugfix/checkout branch. I open this new folder in my IDE and fix the issue. Meanwhile, my work on feature/login remains intact in its own window, with no conflicts. 2. Easier Comparisons: Since branches coexist in separate folders, I can open two IDE windows side-by-side to compare complex files between main and a feature branch, without needing to constantly switch branches and reload the environment. It's the end of git checkout main, check code, git checkout feature, compare. 3. Clean-Environment Testing: Need to test a colleague's branch without cluttering your current environment? Use git worktree add to create a temporary folder, run the tests, and then simply remove the folder and the worktree entry. Essential Commands to Get Started: Add a new worktree: git worktree add <new-folder-path> <branch-name> (Ex: git worktree add ../urgent-hotfix urgent/hotfix) List all active worktrees: git worktree list (To see where each branch is "live" locally) Remove a worktree (after merging, for example): git worktree remove <folder-path> Conclusion git worktree is not just a command; it's a mindset shift that brings sanity to complex workflows. It removes the friction of context switching and allows you to maintain focus on what matters: delivering high-quality code. Did you know or do you already use git worktree? How has it impacted your workflow? Let's chat in the comments! 👇 #Git #DevOps #Productivity #SoftwareDevelopment #Programming #GitWorktree #LinkedinLearning

Git worktree > Git stash (and it’s not even close) Ever had to pause a feature midway… just to fix something urgent? Your brain probably goes: • git stash • checkout main • create branch • fix → commit • come back → stash pop Works… but it’s fragile. You risk: • Merge conflicts during stash pop • Losing untracked changes • Breaking your mental context • Accidentally committing half-baked work I’ve been there more times than I’d like to admit. Then I started using git worktree — and it completely changed how I handle parallel work. What git worktree actually does Git lets you check out the same repository into multiple directories simultaneously. Not branches switching inside one folder. Multiple folders. Multiple working states. Same repo. git worktree add ../hotfix-branch main This creates a new directory: → Clean checkout → Separate working tree → Independent changes Your original feature branch? Untouched. Exactly as you left it. How this changes your workflow Instead of context switching: • Feature A → stays in /project • Urgent fix → /hotfix-branch • Experiment → /experiment-xyz Each task lives in its own isolated workspace No stashing. No juggling. Under the hood (what’s actually happening) Git internally separates: • Working Tree → your files • Index (staging area) • HEAD (current branch reference) git worktree creates: → New working tree → New HEAD pointer → Shared .git object database So: • Commits are shared • History is shared • But working directories are isolated This is why it’s lightweight — no repo duplication. Why it’s insanely useful • Work on multiple features in parallel • Keep long-running branches untouched • Debug production issues without disturbing local state • Run multiple dev servers for different branches And the big one: 👉 Perfect for AI-assisted workflows If you’re using agents/tools: • Worktree 1 → Feature implementation • Worktree 2 → Refactor • Worktree 3 → Bug fix All running in parallel. No branch pollution. No conflicts from half-done work. Cleanup is simple git worktree remove ../hotfix-branch Gone. Clean. The tradeoff (the “secret sauce”) Worktrees shift complexity from Git → filesystem. You now manage: • Multiple folders • Awareness of where you’re working • Disk structure discipline But in return, you get: 👉 Zero context switching overhead The real takeaway Most developers use Git like a linear tool. But Git is actually built for parallelism. git worktree unlocks that. Question If you’re still using git stash as your default escape hatch… Are you solving the problem—or just working around it? #git #softwareengineering #webdevelopment #developerworkflow #productivity

Git Commands git init :- Initialize a new Git repository in your project folder git clone :- Copy an existing remote repository to your local system git status :- Check current state (modified, staged, untracked files) git add . :-Add all files to staging area git add <file> :- Add a specific file to staging git commit -m "message" :- Save staged changes as a snapshot in local repository git push origin main :- Upload local commits to remote repository git pull origin main :- Fetch and merge latest changes from remote git fetch :- Download changes without merging git branch :- List all branches git branch <name> :- Create a new branch git checkout <branch> :- Switch to another branch git checkout -b <branch> :- Create and switch to a new branch git switch <branch> :- Modern way to switch branches git merge <branch> :- Merge a branch into the current branch git rebase <branch> :- Reapply commits on top of another branch for cleaner history git branch -d <branch> :- Delete a branch after merging git log :- View complete commit history git log --oneline :- View compact commit history git show :- Display detailed information about a commit git diff :- Show differences between changes git reset --soft HEAD~1 :- Undo last commit but keep changes staged git reset --hard HEAD :- Reset everything to last commit (use carefully) git stash :- Temporarily save uncommitted work git stash pop :- Restore stashed changes git remote add origin :- Link local repository to a remote git remote -v :- View remote repository URLs git show <commit> :-View details of a specific commit.

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

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

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

Git repositories are really good sources of truth. But right now the interfaces for working with them are almost exclusively designed for engineers. A git repository is really just a folder—a collection of files. We think of them as places to store code, but that’s a limitation we impose, not of the technology. Files could be almost anything—structured data, narrative prose, photos, diagrams… At Button School, we keep all of our learning materials, our internal tools, our website content, and our experiments in a monorepo. We aren’t unique in this: many companies keep documentation in their repo alongside their apps and services. This means that the whole team, me, our learning designer, our product lead, and even our content advisor all work with our repo. Our content can be versioned, we use pull requests to review changes before we finalize them. There are points of friction working this way: it means everyone has an IDE set up on their machines, which is not everyone’s natural working environment. It’s right there in the name Integrated Development Environment. We accept it because of all the other benefits we get from working this way. Non-engineers are already coming into our repos, and there are only going to be more of them. The question of if they should is being answered on its own. We need to answer the question of what kind of tools they need. Where are the content environments, design environments, management environments, product environments that can work with a local repository? What’s the amount of abstraction these kinds of environments should apply? How can environments shaped for these perspectives feel like a working homebase for non-engineers to work with git-based workflows, branches and worktrees and remotes and pull requests and all? What will concepts like linting, package management, environment management, automated testing, project scaffolding look like for content, project management, design concepts, scenario and strategy planning, research ops? How will these environments handle sensitive data that shouldn’t be committed to a repository? How can we make a seamless experience for pulling in data sources and media assets from outside of the repository without them having to set up Docker and environment variables? Can we? As technologists, we’ve spent a ton of energy on developer experience (DX) for the past decade-plus. It’s time to expand that idea outside of this narrow idea that a developer is someone who writes code. Content, strategy, insights, planning, design, experiments: these are all developed as well. Let’s turn our attention to making what has traditionally been our home feel welcoming for everyone else involved in developing digital products. The robots absolutely will not do this for us. This project will take all of us in the same way DX has taken countless small side projects, long conversations, advocacy, standards governance, and education. I really hope we are up for the challenge.

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