[{"_1":2,"_190":-5,"_191":-5},"loaderData",{"_3":4},"resources/routes/resources-git-index",{"_5":6},"commandsByCategory",[7,73,120,160],{"_8":9,"_13":70,"_71":72,"_17":18},"commands",[10,24,29,34,40,45,50,55,60,65],{"_11":12,"_13":14,"_15":16,"_17":18,"_19":12,"_20":21,"_22":23},"command","git add","description","Stage changes to include in your next commit, controlling exactly what gets saved to your repository history.","slug","git-add","tier","tier-1","title","content","\nYou've just finished making changes to several files, but you don't want to\ncommit everything at once. Maybe some changes are ready to go while others are\nstill experimental, or perhaps you want to group related changes into separate\ncommits. This is where `git add` comes in. It's the command that tells Git which\nchanges you want to include in your next commit, moving them from your working\ndirectory to the staging area.\n\nThink of the staging area as a preparation zone for your commit. When you modify\na file, Git notices the change but doesn't automatically include it in your next\ncommit. You have to explicitly add it with `git add`. This might seem like an\nextra step, but it gives you precise control over what goes into each commit.\nYou can make changes to ten files but only commit five of them, keeping your\ncommit history clean and focused.\n\nThe most straightforward use is `git add filename.js`, which stages all changes\nto that specific file. If you've modified `auth.ts` and you're happy with those\nchanges, running `git add auth.ts` prepares them for commit. The file moves to\nthe staging area, and Git will include those changes when you run `git commit`.\nYou can add multiple files at once with `git add file1.js file2.ts file3.css`,\nwhich is handy when you've made related changes across several files.\n\n## Staging Patterns and Options\n\nA common pattern is staging everything at once with `git add .` or `git add -A`.\nThe dot version stages all changes in the current directory and its\nsubdirectories, while `-A` stages everything in the entire repository. Teams\noften use these when all their changes belong together in a single commit. But\nbe careful—it's easy to accidentally stage files you didn't mean to include,\nlike debug logs or temporary test files. Always run `git status` first to see\nwhat you're about to stage.\n\nSometimes you want to stage parts of a file but not everything. You've made two\nunrelated changes to the same file, and they should really be in separate\ncommits. Running `git add -p filename.js` starts an interactive session where\nGit shows you each change and asks if you want to stage it. You can respond with\n'y' to stage a section, 'n' to skip it, or 's' to split it into smaller pieces.\nThis is incredibly useful for maintaining a clean commit history where each\ncommit has a single, clear purpose.\n\n## Working with New and Deleted Files\n\nWhen you create a new file, Git sees it as \"untracked\"—it knows the file exists,\nbut it's not part of the repository yet. Running `git add newfile.js` tells Git\nto start tracking the file and stages it for your next commit. After that first\ncommit, Git tracks the file automatically, and future changes only need to be\nstaged, not the file itself.\n\nDeleting files works similarly. If you delete a file from your filesystem, Git\nnotices it's missing but doesn't automatically stage the deletion. You need to\nrun `git add deleted-file.js` to stage the deletion for commit. Alternatively,\nyou can use `git rm filename.js`, which deletes the file and stages the deletion\nin one step. Most developers use `git add -A` after deleting files since it\ncatches all changes including deletions.\n\n## Pull Request Workflows\n\nIn pull request workflows, staging becomes part of how you tell your story. Each\ncommit in your PR should make sense on its own, solving one problem or adding\none feature. By carefully choosing what to stage, you create a series of commits\nthat reviewers can follow logically. Instead of one massive commit that changes\n50 files, you might make five commits that each focus on a specific aspect of\nyour feature.\n\nSome teams use Git hooks that run checks when you stage files, like linters or\nformatters. When you run `git add`, these hooks might automatically fix\nformatting issues or warn you about problems. If a hook modifies files, you\nmight need to run `git add` again to stage the fixes before committing.\n\nThe staging area gives you a chance to review your changes before committing\nthem. After staging files with `git add`, you can run `git diff --staged` to see\nexactly what you're about to commit. This is your last chance to catch mistakes\nbefore they become part of your repository history. You can also unstage files\nwith `git reset filename.js` if you realize you staged something by mistake.\n\nUnderstanding `git add` means understanding that commits are intentional\nsnapshots of your work, not automatic saves. You choose what to include, when to\ninclude it, and how to organize your changes into meaningful units. This control\nis what makes Git powerful for collaboration—each commit can tell a clear story\nabout what changed and why.\n","readingTime",4,{"_11":25,"_13":26,"_15":27,"_17":18,"_19":25,"_20":28,"_22":23},"git branch","Create, list, rename, and delete branches to organize parallel lines of development and manage features in your Git repository.","git-branch","\nYou're about to start working on a new feature, and you don't want to clutter up\nthe main branch with half-finished code. Or maybe you need to see which branches\nexist in your repository, or clean up old branches after merging pull requests.\n`git branch` is the command for managing branches—creating them, listing them,\nrenaming them, and deleting them when you're done.\n\nRunning `git branch` with no arguments lists all your local branches, with an\nasterisk marking the one you're currently on. This quick overview helps you see\nwhat branches exist and where you are in your repository. The output might show\nmain, develop, and a few feature branches, giving you a sense of what work is\nhappening in the repo.\n\nTo create a new branch, you use `git branch feature-name`, which creates the\nbranch but doesn't switch to it. The new branch starts at your current commit,\npointing to the same place in history as whatever branch you were on when you\ncreated it. Most developers skip this step and use\n`git checkout -b feature-name` or `git switch -c feature-name` instead, which\ncreates the branch and switches to it in one command.\n\n## Managing and Cleaning Up Branches\n\nDeleting branches is common after merging pull requests. Running\n`git branch -d feature-login` deletes the branch, but only if it's been fully\nmerged into your current branch. This safety check prevents you from\naccidentally losing work. If you're certain you want to delete an unmerged\nbranch, use `-D` (capital D) to force deletion. This is useful for abandoning\nexperimental branches or cleaning up work you decided not to pursue.\n\nRemote branches require a different approach. After merging a PR and deleting\nthe branch on GitHub, your local repository still has a reference to the remote\nbranch. Running `git fetch --prune` removes these stale references. You can also\ndelete a remote branch directly with `git push origin --delete branch-name`,\nthough most teams handle this through GitHub's PR interface.\n\n## Listing and Filtering Branches\n\nThe `-a` flag shows all branches, including remote ones: `git branch -a`. This\ngives you a complete view of every branch in your repository and on the remote.\nYou'll see local branches listed normally, and remote branches prefixed with\n`remotes/origin/`. This is helpful when you need to check out a teammate's\nbranch or see what feature branches exist on the remote but not locally.\n\nTo see which branches have been merged into your current branch, use\n`git branch --merged`. This shows branches that are safe to delete because their\nchanges are already incorporated. Conversely, `git branch --no-merged` shows\nbranches with unmerged work, highlighting where active development is happening\nor where you might have forgotten to merge something.\n\n## Renaming and Organizing\n\nIf you misnamed a branch or want to standardize naming conventions,\n`git branch -m old-name new-name` renames it. If you're currently on the branch\nyou want to rename, you can just use `git branch -m new-name`. After renaming a\nbranch you've already pushed, you'll need to push the new name and delete the\nold one from the remote with `git push origin new-name` and\n`git push origin --delete old-name`.\n\nSome teams use branch naming conventions like `feature/add-login`,\n`bugfix/fix-auth-redirect`, or `release/v1.2.0`. These prefixes help organize\nbranches and make it clear what type of work each branch contains. While Git\ndoesn't enforce this, many teams build tooling or CI pipelines that expect\ncertain naming patterns.\n\n## Pull Request Workflows\n\nIn pull request workflows, branches are how you isolate work. Each PR lives on\nits own branch, keeping features independent until they're ready to merge. You\ncreate a branch for your feature, make commits, push to the remote, and open a\nPR. The branch exists until the PR is merged, then you delete it to keep the\nrepository clean.\n\nWhen reviewers want to test your code locally, they use your branch name to\ncheck it out. After you merge a PR, the branch usually gets deleted both on\nGitHub and locally. Many teams configure automatic branch deletion after PR\nmerges to prevent accumulation of dead branches.\n\nChecking out remote branches requires creating a local tracking branch. If\nsomeone pushes a branch called `experiment-with-caching` and you want to work on\nit, you run `git checkout experiment-with-caching` (after fetching). Git\nautomatically creates a local branch that tracks the remote one, so your pushes\nand pulls go to the right place.\n\nUnderstanding branches means understanding that they're lightweight pointers to\ncommits, not copies of your entire codebase. Creating a branch is instant and\ncheap, which is why developers create branches freely for every feature, bugfix,\nor experiment. Branches let you work on multiple things in parallel without\ninterference, making them fundamental to Git's flexibility and power.\n",{"_11":30,"_13":31,"_15":32,"_17":18,"_19":30,"_20":33,"_22":23},"git checkout","Switch between branches, restore working tree files, or explore specific commits in your Git repository with checkout.","git-checkout","\nYou need to switch to a different branch, or maybe you want to see what your\ncode looked like three commits ago, or you've made changes to a file that you\nwant to discard. `git checkout` is the command you reach for when you need to\nmove between branches or restore files to a previous state. It's one of the most\nfrequently used Git commands, but it actually does several different things\ndepending on how you use it.\n\nThe most common use is switching branches. When you run\n`git checkout feature-login`, Git updates your working directory to match that\nbranch, moving your HEAD pointer to point at the latest commit on that branch.\nAny files that differ between your current branch and the target branch get\nupdated to match the target. If you have uncommitted changes that would conflict\nwith the switch, Git stops and asks you to commit or stash them first.\n\nBut checkout does more than just switch branches. You can also use it to create\na new branch and switch to it in one step with `git checkout -b refactor-auth`.\nThis is equivalent to running `git branch refactor-auth` followed by\n`git checkout refactor-auth`, but it's faster and more common in practice. Most\ndevelopers create branches this way rather than using the separate branch\ncommand.\n\n## Working with Specific Commits and Files\n\nSometimes you need to look at code from a specific point in history without\ncreating a branch. Running `git checkout a3f5b2c` checks out that specific\ncommit, putting you in what Git calls a \"detached HEAD\" state. This is useful\nfor investigating when a bug was introduced or seeing what the code looked like\nbefore a major refactoring. You're not on any branch, so any commits you make\nwon't belong to a branch unless you create one. If you want to build on that\ncommit, create a branch from there with `git checkout -b fix-from-old-state`.\n\nYou can also use checkout to restore individual files from different commits or\nbranches. Say you're working on a feature branch and you realize you need the\nversion of `database.config.js` from the main branch. Running\n`git checkout main -- database.config.js` pulls just that file from main into\nyour working directory. This is particularly useful when you've made\nexperimental changes to a file and want to start over, or when you need to grab\na specific file from another branch without merging everything.\n\nThe most common use case for this is discarding local changes. If you've been\nexperimenting with `api-client.ts` and want to throw away your changes and get\nback to the last committed version, `git checkout -- api-client.ts` does exactly\nthat. Just be careful—those changes are gone once you run this. There's no undo.\n\n## Pull Request Workflows\n\nWhen working on pull requests, checkout becomes essential for reviewing other\npeople's code. If someone opens a PR from the branch `add-user-permissions`, you\ncan check out their branch locally with `git checkout add-user-permissions`\n(after fetching) to run their code, test it, and see how it integrates with your\nwork. Many teams have a workflow where they check out PR branches locally before\napproving them, especially for changes that affect critical systems or need\nmanual testing.\n\nGit has started splitting checkout's functionality into more focused commands.\n`git switch` handles branch switching, and `git restore` handles file\nrestoration. These newer commands are clearer about what they do, but checkout\nstill works and most developers still use it out of habit. The functionality is\nidentical—it's just a matter of whether you prefer the traditional Swiss Army\nknife command or the more explicit alternatives.\n\nThe key thing to remember about checkout is that it changes what you're looking\nat in your working directory. Whether you're switching branches to work on a\ndifferent feature, grabbing a file from elsewhere, or investigating old code,\nyou're always moving between different states of your repository. Understanding\nthis makes checkout feel less like several unrelated commands and more like\nvariations on the same core idea.\n",{"_11":35,"_13":36,"_15":37,"_17":18,"_19":35,"_20":38,"_22":39},"git commit","Save your staged changes to the repository history with a descriptive commit message explaining what you changed and why.","git-commit","\nYou've staged your changes with `git add`, and now you're ready to save them to\nyour repository's history. `git commit` creates a permanent snapshot of\neverything in your staging area, along with a message describing what you\nchanged and why. Unlike saving a file in an editor, commits are immutable\nrecords that become part of your project's timeline. Once you commit, those\nchanges are preserved in Git's history, making it easy to review, revert, or\nunderstand what happened later.\n\nThe basic form is `git commit -m \"Add user authentication\"`, where the `-m` flag\nlets you write your commit message directly in the command. The message should\ndescribe what the commit does and ideally why you made the change. Good commit\nmessages help your teammates (and future you) understand your reasoning without\nhaving to read through all the code changes. Instead of \"fix bug,\" write \"Fix\nlogin redirect loop when session expires\" so it's clear what problem you solved.\n\nIf you skip the `-m` flag and just run `git commit`, Git opens your default text\neditor where you can write a longer, more detailed message. The first line\nshould be a brief summary (50 characters or less), followed by a blank line,\nthen a more detailed explanation if needed. This format works well for complex\nchanges that need more context. Many teams have conventions about how to format\nthese messages, like starting with a verb in the imperative mood (Add, Fix,\nUpdate) or including ticket numbers.\n\n## Amending and Refining Commits\n\nSometimes you commit too early and realize you forgot to include a file or made\na typo in your code. Running `git commit --amend` lets you add new staged\nchanges to your most recent commit, or just update the commit message. If you've\nstaged new changes, they get folded into the previous commit as if you'd\nincluded them from the start. If you haven't staged anything, you're just\nediting the message. This is handy for small fixes before you push your work,\nbut be careful—amending changes the commit's identity, so don't amend commits\nyou've already pushed to a shared branch.\n\nThe `-a` flag provides a shortcut for committing all changes to tracked files\nwithout explicitly staging them first. Running\n`git commit -a -m \"Update API documentation\"` automatically stages all\nmodifications to files Git is already tracking, then commits them. This doesn't\ninclude new untracked files—you still have to `git add` those explicitly. Many\ndevelopers use `-a` for quick commits when they know all their changes belong\ntogether, though it's safer to review with `git add` and `git status` for\nimportant changes.\n\n## Pull Request Context\n\nIn pull request workflows, each commit tells part of your story. Reviewers look\nat your commits to understand how you built the feature, not just what the final\nresult looks like. Clean, focused commits make reviews faster because each one\nsolves a specific problem or adds a specific feature. Instead of committing\neverything at once in a single \"implement feature\" commit, you might make\nseparate commits for \"Add database schema,\" \"Implement API endpoints,\" and \"Add\nfrontend components.\"\n\nSome teams enforce commit message conventions through Git hooks or CI checks.\nThey might require that messages reference a ticket number like \"PROJ-123: Add\npassword reset flow\" or follow a specific format like Conventional Commits\n(feat:, fix:, docs:). If your commit message doesn't match the pattern, the\ncommit is rejected, and you need to amend it. These conventions make it easier\nto generate changelogs, track which changes relate to which issues, and maintain\nconsistent history across the team.\n\nEmpty commits are possible with\n`git commit --allow-empty -m \"Trigger CI rebuild\"`, which creates a commit with\nno changes. This is occasionally useful for retriggering CI pipelines or marking\nspecific points in history, but it's uncommon in day-to-day work. Most commits\nshould contain actual changes.\n\n## Commit Signing and Verification\n\nSome organizations require signed commits using GPG or SSH keys. When enabled,\nrunning `git commit -S -m \"message\"` signs the commit cryptographically, proving\nthat you're the author. Platforms like GitHub display a \"Verified\" badge next to\nsigned commits, which helps prevent impersonation and ensures commits haven't\nbeen tampered with. If your team uses signing, you'll configure your GPG key\nonce, and then adding `-S` (or setting it as default) becomes part of your\ncommit workflow.\n\nThe key to effective commits is thinking of them as documentation. Each commit\nshould be a logical unit of work that makes sense on its own. If you're fixing a\nbug, the commit should contain only the fix, not unrelated cleanup or new\nfeatures. If you're adding a feature, break it into steps that each leave the\ncodebase in a working state. This discipline pays off during code review, when\ndebugging, and when you need to roll back changes without losing unrelated work.\n\nCommits are your project's memory. They capture not just what changed, but when\nand why. A well-crafted series of commits tells the story of how your feature\ncame together, making it easy for anyone (including future you) to understand\nthe evolution of your code.\n",5,{"_11":41,"_13":42,"_15":43,"_17":18,"_19":41,"_20":44,"_22":39},"git diff","See exactly what changed in your files, comparing between commits, branches, or your working directory and staging area.","git-diff","\nYou've been editing code for the past hour, and you want to see exactly what you\nchanged before committing. Or you need to compare your feature branch with main\nto understand how they differ. `git diff` shows the exact changes between two\nstates in your repository—line by line additions and deletions, helping you\nreview work before saving it or understand differences between versions.\n\nRunning `git diff` with no arguments shows unstaged changes in your working\ndirectory. These are modifications you've made to tracked files but haven't run\n`git add` on yet. The output shows which files changed, with lines you added\nmarked with `+` and lines you removed marked with `-`. Context lines around the\nchanges help you see where in the file the modifications occurred. This is your\nlast chance to review changes before staging them for commit.\n\nOnce you've staged files with `git add`, `git diff` no longer shows those\nchanges because they're no longer \"unstaged.\" To see staged changes—what will go\ninto your next commit—use `git diff --staged` or `git diff --cached` (they're\nthe same thing). This shows exactly what you're about to commit, giving you a\nfinal review opportunity before running `git commit`.\n\n## Comparing Branches and Commits\n\nTo see differences between branches, use `git diff main..feature-branch`. This\nshows what's different between main and your feature branch, highlighting all\nthe work you've done. The order matters: `git diff feature-branch..main` shows\nthe reverse comparison. This is essential before merging or opening a pull\nrequest, as it shows what will change when the branches combine.\n\nYou can also compare specific commits with their SHA hashes:\n`git diff a3f5b2c b8e9d1f`. This shows what changed between those two commits,\nwhich is useful when debugging to see what a specific commit did. To see what a\nsingle commit changed, use `git diff a3f5b2c^..a3f5b2c` or the simpler\n`git show a3f5b2c`.\n\n## Filtering and Focusing Diffs\n\nAdding a filename shows changes only for that file: `git diff filename.js`. This\nnarrows the output to just what you care about, avoiding the noise of unrelated\nchanges. You can specify multiple files or use patterns:\n`git diff src/*.test.js` shows changes to all test files in the src directory.\n\nThe `--stat` flag provides a summary instead of full diffs: `git diff --stat`\nshows which files changed and how many lines were added or removed in each. This\noverview helps you understand the scope of changes without reading through all\nthe code. For even more detail, `--numstat` provides machine-readable counts\nuseful for scripts or metrics.\n\n## Word-Level and Whitespace Handling\n\nSometimes changes are within a line rather than entire lines being added or\nremoved. The `--word-diff` flag shows word-by-word changes instead of\nline-by-line, making it easier to spot small modifications like variable renames\nor typo fixes within long lines. Words removed appear in brackets, words added\nin braces, making subtle changes more visible.\n\nWhitespace-only changes can clutter diffs, especially after running formatters.\nThe `-w` flag ignores whitespace changes, showing only substantive\nmodifications: `git diff -w`. This is useful when reviewing code where\nindentation changed but logic didn't, or after reformatting files with Prettier\nor similar tools.\n\n## Pull Request Review\n\nIn pull request workflows, diff is central to code review. When reviewing a PR\non GitHub, you're essentially looking at `git diff main..feature-branch`\nformatted in a web interface. Understanding how to generate the same view\nlocally helps you review more thoroughly, especially for large PRs where you\nwant to test the code while reviewing.\n\nBefore opening a PR, running `git diff main..HEAD` shows exactly what you're\nproposing to merge. If the diff is huge, you might want to split your work into\nmultiple PRs. If it includes files you didn't mean to change, you can fix those\nbefore pushing. This review step catches mistakes before they become part of the\npublic PR discussion.\n\n## Diff Tools and Integration\n\nSome changes are easier to understand with visual diff tools. Running\n`git difftool` instead of `git diff` launches a configured visual diff program\nlike Meld, Beyond Compare, or Kaleidoscope. These tools show changes\nside-by-side with highlighting and navigation controls, which can be easier than\nreading terminal output for complex changes.\n\nMany editors and IDEs integrate Git diff directly into their interface. VS Code,\nIntelliJ, and others show changed lines in the gutter, let you click to see what\nchanged, and offer inline diff views. These integrated tools use `git diff`\nunder the hood but present the information in more accessible ways.\n\n## Diffing Between Different Files\n\nYou can compare two different files with\n`git diff --no-index file1.js file2.js`, which doesn't require either file to be\nin a Git repository. This turns Git into a general-purpose diff tool for any\ntext files, using its robust diff algorithm even outside version control\ncontexts.\n\nUnderstanding diff means understanding that Git tracks changes, not files. Every\ncommit is a set of changes relative to its parent. Diff exposes those changes,\nletting you see exactly what's different between any two points in your\nrepository's history. Whether you're reviewing your own work before committing,\nunderstanding what a teammate changed in their PR, or debugging by comparing\nversions, diff is the tool that makes those comparisons clear and precise.\n",{"_11":46,"_13":47,"_15":48,"_17":18,"_19":46,"_20":49,"_22":39},"git log","View and filter the history of commits in your repository, showing who changed what, when, and why with powerful formatting options.","git-log","\nYou need to see what changed in the last week, or track down when a specific\nfeature was added, or understand how a file evolved over time. `git log` shows\nyour repository's commit history, displaying commits in reverse chronological\norder with their messages, authors, and dates. It's your window into the\nrepository's past, helping you understand what happened and why.\n\nRunning `git log` by itself shows the full history of the current branch. Each\ncommit gets a display showing its SHA hash, author, date, and commit message.\nThe most recent commit appears first, and you can scroll through older commits.\nPress `q` to exit the log viewer. This default view is comprehensive but can be\noverwhelming for repositories with thousands of commits.\n\nThe `--oneline` flag provides a compact view with one commit per line:\n`git log --oneline`. Each line shows the abbreviated commit hash and the first\nline of the commit message. This condensed format makes it easy to scan recent\nhistory quickly or see how many commits are in a range. It's probably the most\ncommonly used variant of log because it gives you enough information without\ncluttering your terminal.\n\n## Filtering and Searching History\n\nYou can limit the number of commits shown with `-n`, like `git log -5` for the\nfive most recent commits. This is useful when you just want to see recent\nactivity without scrolling through years of history. Combining this with\n`--oneline` gives you a quick snapshot: `git log --oneline -10` shows the last\nten commits in compact form.\n\nTo see history for a specific file, add the filename: `git log -- filename.js`.\nThis shows only commits that modified that file, which is invaluable for\ntracking down when a bug was introduced or understanding how a piece of code\nevolved. You can also see the actual changes with `git log -p -- filename.js`,\nwhich shows the diff for each commit affecting that file.\n\nDate ranges help narrow your search to specific time periods. Running\n`git log --since=\"2 weeks ago\"` shows commits from the past two weeks, while\n`git log --since=\"2024-01-01\" --until=\"2024-06-30\"` shows commits from the first\nhalf of 2024. You can use natural language like \"yesterday,\" \"last week,\" or\nspecific dates in various formats.\n\n## Visualizing Branch History\n\nThe `--graph` flag draws an ASCII representation of branch structure alongside\nthe commits: `git log --graph --oneline --all`. This visualization shows where\nbranches split and merge, making it clear how parallel work came together. It's\nespecially useful for understanding complex histories with multiple feature\nbranches merging into main.\n\nAdding `--all` shows commits from all branches, not just the current one.\nWithout this flag, you only see commits reachable from your current branch,\nwhich can hide work happening on other branches. Combining `--graph`,\n`--oneline`, and `--all` gives you a comprehensive overview of all activity\nacross all branches in compact form.\n\n## Searching for Specific Changes\n\nThe `-S` flag searches for commits that added or removed specific text:\n`git log -S \"function calculateTotal\"`. This is incredibly useful for finding\nwhen a function was introduced or deleted. Unlike grepping through current\nfiles, this searches through every version in history. If you're debugging and\nwant to know when a particular method appeared in the codebase, this finds it.\n\nYou can also search commit messages with `--grep`: `git log --grep=\"fix bug\"`\nshows commits whose messages contain \"fix bug.\" This works well if your team\nuses consistent commit message conventions, like including ticket numbers or\nkeywords. Combine with `-i` for case-insensitive searching:\n`git log --grep=\"JIRA-123\" -i`.\n\n## Formatting and Customization\n\nThe `--pretty` flag lets you customize output format. Using\n`--pretty=format:\"%h - %an, %ar : %s\"` shows abbreviated hash, author name,\nrelative date, and subject in a custom layout. Many developers create Git\naliases for their preferred log formats, so they can type `git lg` and get their\ncustomized view without remembering complex format strings.\n\nFor visual learners, many GUI tools like GitKraken, SourceTree, or the GitHub\nDesktop app provide graphical log views with clickable commits and visual branch\ndiagrams. These can be easier to navigate than terminal output, though\nunderstanding the command-line version helps when you're working on servers or\nin terminals.\n\n## Pull Request Context\n\nIn pull request workflows, log helps you review what's about to be merged.\nBefore approving a PR, you might check out the branch and run\n`git log main..feature-branch` to see all commits that are in the feature branch\nbut not in main. This shows exactly what the PR will add to the codebase.\n\nAfter merging PRs, log helps you generate changelogs or release notes. You can\nreview all commits since the last release with `git log v1.0.0..HEAD`, then\nsummarize the changes for your users. Many teams automate this with tools that\nparse commit messages following conventions like Conventional Commits.\n\nUnderstanding log means understanding that your repository's history tells a\nstory. Each commit is a chapter explaining what changed and why. Good commit\nmessages turn that history into documentation that helps future developers\n(including future you) understand decisions, trace bugs, and learn how the\ncodebase evolved. Log is how you read that story.\n",{"_11":51,"_13":52,"_15":53,"_17":18,"_19":51,"_20":54,"_22":39},"git merge","Combine changes from different branches, integrating feature work into main or incorporating updates from teammates.","git-merge","\nYou've finished working on a feature branch, your pull request has been\napproved, and now you need to integrate those changes into main. Or perhaps\nyou're on a feature branch and want to pull in the latest updates from main to\nstay current. `git merge` combines the histories of two branches, creating a new\ncommit that ties them together.\n\nThe basic flow is to check out the branch you want to merge into, then run\n`git merge branch-name` to merge the other branch in. If you're on main and run\n`git merge feature-login`, Git brings all commits from feature-login into main.\nIf the branches haven't diverged—meaning feature-login is just ahead of main\nwith new commits—Git performs a \"fast-forward\" merge by simply moving the main\nbranch pointer forward. No merge commit is created because there's nothing to\nmerge; main just catches up to feature-login.\n\nWhen both branches have new commits, Git creates a merge commit that combines\nboth histories. This commit has two parents, representing where the branches\nsplit and where they came back together. The merge commit appears in your\nhistory as a marker of when the integration happened, and it includes a default\nmessage like \"Merge branch 'feature-login' into main.\" You can customize this\nmessage or keep the default.\n\n## Handling Merge Conflicts\n\nConflicts happen when both branches modified the same lines in the same files.\nGit can't automatically decide which changes to keep, so it stops the merge and\nasks you to resolve the conflicts manually. You'll see files marked with\nconflict markers showing both versions, and Git lists the conflicted files. You\nedit each one, choosing which changes to keep, remove the markers, then stage\nthe resolved files with `git add` and complete the merge with `git commit`.\n\nIf you run into conflicts you're not ready to handle, `git merge --abort`\ncancels the merge and returns your branch to its state before you started. This\nis useful when you realize you need to understand the conflicting changes better\nor coordinate with the person who wrote the other code.\n\n## Merge Strategies and Options\n\nBy default, Git creates merge commits when histories have diverged, but\n`git merge --no-ff` forces a merge commit even for fast-forward merges. This\npreserves a record of the branch existing, which some teams prefer for tracking\nwhen features were integrated. The opposite is `git merge --ff-only`, which\nfails if a fast-forward isn't possible, preventing unexpected merge commits.\n\nThe `--squash` option combines all commits from the merged branch into a single\ncommit on your current branch. Running `git merge --squash feature-login` brings\nall the changes from feature-login, but instead of creating a merge commit, it\nstages everything for you to commit manually. This creates a cleaner history\nwith one commit per feature instead of dozens of small commits, though you lose\nthe detailed commit history from the feature branch.\n\n## Pull Request Integration\n\nIn pull request workflows, merging usually happens through the platform's\ninterface (GitHub, GitLab, etc.) rather than manually. When you click \"Merge\npull request,\" the platform runs `git merge` on the server, integrating your\nbranch into the target branch. Different platforms offer different merge\nstrategies: regular merge commits, squash merges that combine commits, or\nrebase-and-merge that replays commits without a merge commit.\n\nEven though the PR platform handles the final merge, you often merge locally\nduring development. If main has advanced while you were working on your feature\nbranch, you might merge main into your feature branch to stay up to date. This\nensures your PR will merge cleanly when approved and lets you test that your\nfeature works with the latest code.\n\n## Three-Way Merges and Ancestry\n\nGit's merge algorithm is a \"three-way merge\" that looks at three points: the\ncommon ancestor of both branches, the tip of the current branch, and the tip of\nthe branch being merged. By comparing all three, Git can intelligently determine\nwhat changes were made by each branch and how to combine them. This is more\nsophisticated than a simple two-way diff and allows Git to automatically resolve\nmany potential conflicts.\n\nWhen merging fails with complex conflicts, you might want more context about\nwhat happened. Running `git log --graph --oneline --all` after a failed merge\nshows the branch structure and helps you understand how the branches diverged.\nSome developers use visual merge tools configured with `git mergetool` to\nresolve conflicts with a graphical interface instead of editing conflict markers\nmanually.\n\nAfter a successful merge, the merged branch still exists. If you merged\nfeature-login into main, feature-login remains as a branch pointing to its last\ncommit. You typically delete feature branches after merging with\n`git branch -d feature-login`, which keeps your branch list clean. GitHub and\nother platforms often do this automatically when you merge pull requests.\n\nUnderstanding merge means understanding that Git is combining two parallel\ntimelines into one. Sometimes that combination is trivial (fast-forward),\nsometimes Git can do it automatically (three-way merge with no conflicts), and\nsometimes you need to make decisions (resolving conflicts). The key is knowing\nwhich type of merge you want and being prepared to handle conflicts when they\narise.\n",{"_11":56,"_13":57,"_15":58,"_17":18,"_19":56,"_20":59,"_22":39},"git pull","Fetch changes from a remote repository and automatically merge or rebase them into your current branch to stay up to date.","git-pull","\nYour teammate just merged their pull request into main, and you need those\nchanges in your local repository. Or you're working on a feature branch and want\nto incorporate the latest updates from main. `git pull` fetches changes from the\nremote repository and merges them into your current branch, keeping your local\ncode in sync with what's on the server.\n\nRunning `git pull` is actually a combination of two commands: `git fetch` (which\ndownloads commits from the remote) and `git merge` (which integrates those\ncommits into your current branch). When you're on main and run `git pull`, Git\ndownloads any new commits from `origin/main` and merges them into your local\nmain branch. If there are no conflicts, the merge happens automatically and your\nworking directory updates to include the new changes.\n\nThe default behavior merges changes, which creates a merge commit if your local\nbranch has diverged from the remote. If both you and a teammate have made\ncommits, pulling creates a commit that ties both histories together. Some\ndevelopers find these merge commits cluttering, especially for simple cases\nwhere they just want to get the latest code. That's where pull options come in\nhandy.\n\n## Rebase Instead of Merge\n\nRunning `git pull --rebase` changes the behavior to rebase your local commits on\ntop of the incoming changes instead of merging. If you've made two commits\nlocally and someone else pushed three commits, rebase replays your two commits\nas if you made them after their three. This creates a linear history without\nmerge commits, which many teams prefer for cleaner logs. The downside is that\nrebasing rewrites your local commits, giving them new identifiers, which can\ncause problems if you've already pushed those commits and someone else has based\nwork on them.\n\nMany developers configure Git to always rebase when pulling with\n`git config pull.rebase true`. This makes `git pull` behave like\n`git pull --rebase` by default, keeping their history linear without thinking\nabout it. If you work on a team that values clean history, this configuration is\ncommon.\n\n## Handling Conflicts\n\nWhen pulling results in conflicts—cases where you and someone else changed the\nsame lines of code—Git stops and asks you to resolve them manually. You'll see\nfiles marked with conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), showing\nboth versions of the conflicting changes. You edit the files to keep what you\nwant, remove the markers, stage the resolved files with `git add`, and complete\nthe merge with `git commit`. If you pulled with `--rebase`, you'd use\n`git rebase --continue` instead after staging the fixed files.\n\nIf conflicts feel overwhelming or you realize you pulled at a bad time,\n`git merge --abort` (or `git rebase --abort` if rebasing) cancels the pull and\nreturns your branch to its state before you started. This lets you clean up your\nworking directory or commit your current work before trying to pull again.\n\n## Pull Request Workflows\n\nIn pull request workflows, pulling happens in a couple of contexts. First, you\nregularly pull main to keep your feature branch up to date. You might switch to\nmain with `git checkout main`, pull the latest with `git pull`, then switch back\nto your feature branch and merge or rebase main into it. This ensures your PR\nwill merge cleanly when approved.\n\nSecond, you pull your own feature branch when working across multiple machines\nor when other contributors have pushed commits to your PR branch. If you push\ncommits from your laptop, then later want to continue work on your desktop, you\npull the feature branch to download those commits. Some teams also push commits\ndirectly to each other's PR branches when pair programming or helping fix\nissues.\n\n## Fast-Forward and Behavior Modes\n\nWhen your local branch hasn't diverged from the remote—you haven't made any\nlocal commits—pulling can \"fast-forward\" instead of merging. This just moves\nyour branch pointer forward to match the remote without creating a merge commit.\nIt's the simplest case and happens often when you're just staying up to date\nwith main.\n\nGit has three modes for handling divergent histories when pulling: merge (create\na merge commit), rebase (replay your commits), and fast-forward only (fail if\nfast-forward isn't possible). You can set the default behavior with\nconfiguration or specify it per-pull with flags like `--ff-only`, which prevents\naccidental merges by only allowing pulls that can fast-forward.\n\n## Pull Specific Branches\n\nWhile `git pull` pulls the current branch's upstream by default, you can pull\nother branches with `git pull origin branch-name`. This fetches and merges that\nspecific branch into your current branch, which is useful when you want to\nincorporate changes from a teammate's feature branch directly without switching\nto it first.\n\nUnderstanding pull means understanding that it's your primary way of getting\nother people's work onto your machine. Pull keeps you synced with the team,\nensures you're building on the latest code, and helps prevent the drift that\nleads to painful merge conflicts later. The key decision is whether to merge or\nrebase when pulling—both work, but your team's conventions and the state of your\nlocal commits should guide which approach you use.\n",{"_11":61,"_13":62,"_15":63,"_17":18,"_19":61,"_20":64,"_22":39},"git push","Upload your local commits to a remote repository, sharing your work with teammates and triggering CI pipelines.","git-push","\nYou've made commits locally, and now you want to share them with your team or\nback them up to GitHub. `git push` uploads your commits to a remote repository,\nmaking them visible to everyone with access. It's how your work moves from your\ncomputer to the shared codebase, triggering pull request updates, CI pipelines,\nand team notifications.\n\nThe basic form is just `git push`, which pushes commits from your current branch\nto its configured upstream branch on the remote. If you're on `feature-login`\nand it's tracking `origin/feature-login`, your commits go there. The first time\nyou push a new branch, you need to tell Git where to push with\n`git push -u origin feature-login`. The `-u` flag (short for `--set-upstream`)\nsets up tracking so future pushes on this branch just need `git push` without\nspecifying the remote or branch name.\n\nWhen you push, Git compares your local commits with what's on the remote. If\nyour branch has commits that the remote doesn't, Git uploads them. If someone\nelse has pushed commits you don't have, Git refuses to push and tells you to\npull first. This prevents you from accidentally overwriting someone else's work.\nYou'll see an error like \"updates were rejected because the remote contains work\nthat you do not have locally,\" which means you need to run `git pull` to merge\ntheir changes before pushing yours.\n\n## Force Pushing and Overwrites\n\nSometimes you need to override the remote branch completely, replacing its\nhistory with yours. This happens after rebasing or amending commits you've\nalready pushed. Running `git push --force` does this, but it's dangerous—it can\ndelete other people's commits if they've pushed work you don't have. A safer\nalternative is `git push --force-with-lease`, which only succeeds if the remote\nbranch hasn't changed since you last fetched. If someone else pushed in the\nmeantime, the push fails, protecting their work.\n\nForce pushing is common in pull request workflows where you're the only person\nworking on your feature branch. You push initial commits, get feedback, then\nrebase to incorporate review comments or clean up your commit history. After\nrebasing, a normal push fails because you've rewritten history, so you use\n`--force-with-lease` to update the PR. Just never force push to shared branches\nlike main or develop—that can cause serious problems for your team.\n\n## Push Specific Branches and Tags\n\nYou can push specific branches with `git push origin branch-name`, which is\nuseful when you have multiple local branches and only want to push one. To push\nall branches at once, use `git push --all`, though this is less common since it\ncan accidentally push work-in-progress branches you meant to keep local.\n\nTags work differently from branches. By default, `git push` doesn't upload tags.\nYou need `git push --tags` to push all tags, or `git push origin v1.2.0` to push\na specific tag. Teams use tags to mark releases, so pushing a version tag might\ntrigger deployment pipelines or create GitHub releases.\n\n## Pull Request Integration\n\nIn pull request workflows, pushing is how you update your PR. When you push\ncommits to a branch with an open PR, platforms like GitHub automatically update\nthe PR to show your new commits. CI checks rerun, reviewers get notified, and\nyour changes become visible immediately. This tight integration means you can\niterate on feedback by making changes locally, committing, and pushing—the PR\nupdates automatically.\n\nSome teams configure branch protection rules that require status checks to pass\nbefore you can push to certain branches. If you try to push directly to main and\ntests are failing, the push gets rejected. This encourages using pull requests\nfor code review rather than pushing directly to protected branches.\n\nAfter your PR is merged, you typically delete the remote feature branch with\n`git push origin --delete feature-branch`. This keeps the remote repository\nclean and makes it clear which branches are still active. GitHub offers a button\nto delete branches automatically after merging PRs, which most teams enable.\n\n## Push Hooks and CI Triggers\n\nWhen you push, remote Git hooks can run checks before accepting your commits.\nThese might verify commit message format, run tests, or check for security\nissues. If a hook rejects your push, you'll see an error message explaining why.\nYou'll need to fix the problem locally and push again.\n\nPushing also triggers continuous integration pipelines. The moment your commits\nreach the remote, CI systems like GitHub Actions start building your code,\nrunning tests, and performing other automated checks. When working on a PR, you\nsee the results as status checks that appear on the pull request page within\nminutes.\n\nUnderstanding push means understanding that it's the bridge between your local\nwork and team collaboration. Until you push, your commits are invisible to\neveryone else. Once you push, they become part of the shared history, ready for\nreview, testing, and integration. The key is knowing when to push (regularly to\nback up work and update PRs) and when to be careful (force pushing to shared\nbranches or pushing untested code to protected branches).\n",{"_11":66,"_13":67,"_15":68,"_17":18,"_19":66,"_20":69,"_22":23},"git status","Check which files have been modified, what is staged for commit, and view the current state of your working directory and branch.","git-status","\nBefore you commit, before you switch branches, before you push—you run\n`git status`. It's the command you use to get your bearings in Git, showing you\nwhich files have changed, what's staged for the next commit, and what's still\nuntracked. Think of it as Git's way of answering \"what's going on right now?\"\nIt's one of the safest commands you can run because it only reads information,\nnever modifies anything.\n\nWhen you run `git status`, you see three categories of files. First, changes\nstaged for commit—these are files you've run `git add` on and will be included\nin your next commit. Second, changes not staged for commit—files Git is tracking\nthat you've modified but haven't staged yet. Third, untracked files—new files\nthat Git doesn't know about yet. This breakdown makes it immediately clear what\nwill happen when you commit and what's still waiting for attention.\n\nThe output shows your current branch and whether it's ahead, behind, or in sync\nwith the remote. If you see \"Your branch is ahead of 'origin/main' by 2\ncommits,\" you know you have local commits that haven't been pushed yet. If it\nsays \"Your branch is behind,\" someone else has pushed changes you don't have\nlocally. This context helps you avoid conflicts and understand where your work\nstands relative to your team's.\n\n## Working with Modified Files\n\nWhen files appear under \"Changes not staged for commit,\" Git tells you exactly\nwhat to do with them. It reminds you to use `git add` to stage them for commit\nor `git restore` to discard changes. These hints make status useful not just for\ninformation but as a guide for your next step. If you've modified ten files but\nonly meant to change three, status shows you which ones have changed so you can\nstage selectively.\n\nRed and green coloring (in terminals that support it) provides quick visual\nfeedback. Modified files appear in red, staged files in green. You can scan the\noutput instantly to see what's ready to commit versus what still needs staging.\nIf everything's green and the working tree is clean, you're safe to switch\nbranches or pull updates without worrying about conflicts.\n\n## Short Format and Porcelain\n\nFor experienced developers who want less verbose output, `git status -s`\nprovides a compact view. Each file gets a two-letter code: `M` for modified, `A`\nfor added, `D` for deleted, and `??` for untracked. The first letter represents\nthe staging area, the second represents the working directory. So `M ` means\nmodified and staged, ` M` means modified but not staged, and `MM` means\nmodified, staged, then modified again. Once you learn this format, you can scan\nstatus updates much faster.\n\nScripts and tools use `git status --porcelain` to get machine-readable output\nthat doesn't change format across Git versions. This stable format makes it\nreliable for automation, though humans rarely use it directly. If you're writing\na script that needs to check repository state, porcelain mode ensures your\nscript won't break when Git's human-readable output format changes.\n\n## Pull Request Workflow\n\nIn pull request workflows, status becomes your checklist before pushing. You run\nit before committing to verify you're staging the right files. You run it before\nswitching branches to make sure you won't lose uncommitted work. You run it\nafter pulling changes to see if there are conflicts. It's the command that keeps\nyou oriented as you move through your workflow.\n\nWhen reviewing a pull request locally, checking out someone else's branch and\nrunning `git status` shows whether the branch is clean or has uncommitted\nchanges. If status shows modified files you didn't change, something's\nwrong—maybe there's a merge conflict or local configuration differences. A clean\nstatus means the branch is exactly as the author pushed it.\n\nMany developers have muscle memory that includes running status constantly.\nAfter modifying files, before committing, after switching branches—status\nbecomes a reflex that keeps you aware of your repository's state. It's also\nforgiving—you can run it as many times as you want without any consequences,\nmaking it perfect for checking your work before taking action.\n\nUnderstanding status output helps you understand Git's three-stage model:\nworking directory (where you edit files), staging area (where you prepare\ncommits), and repository history (where commits are saved). Status shows you the\nrelationship between these stages, making it clear what needs to move where\nbefore you can commit or switch branches.\n","The most frequently used Git commands for daily development work.","name","Essential Daily Commands",{"_8":74,"_13":118,"_71":119,"_17":79},[75,82,88,93,98,103,108,113],{"_11":76,"_13":77,"_15":78,"_17":79,"_19":76,"_20":80,"_22":81},"git cherry-pick","Apply specific commits from one branch to another, selectively incorporating changes without merging everything.","git-cherry-pick","tier-2","\nYou've fixed a critical bug on your feature branch, and you need that same fix\nin the release branch immediately, but you can't merge the entire feature branch\nbecause it contains unfinished work. `git cherry-pick` lets you apply specific\ncommits to your current branch, copying changes without bringing the whole\nhistory along.\n\nRunning `git cherry-pick abc123` while on the release branch applies the commit\nabc123 to your current branch. Git creates a new commit with the same changes\nand message, but with a different SHA because its parent commit is different.\nThis is perfect for backporting bug fixes, porting features between branches, or\nrecovering specific commits from abandoned branches.\n\nYou can cherry-pick multiple commits at once with\n`git cherry-pick abc123 def456 ghi789`, or a range with\n`git cherry-pick abc123..ghi789`. If conflicts occur—the code changed\ndifferently in both places—Git stops and asks you to resolve them, just like\nwith merge or rebase. After resolving and staging files,\n`git cherry-pick --continue` finishes the operation.\n\nIn pull request workflows, cherry-pick helps when you realize a commit belongs\non a different branch. Maybe you committed a fix to the wrong branch, or you\nneed to create a hotfix from work that's part of a larger feature. Cherry-pick\nlets you grab exactly what you need without complex branch manipulation.\n\nUnderstanding cherry-pick means understanding that it duplicates commits across\nbranches. The original commit stays where it is, and a new commit with the same\nchanges appears on your current branch. This can create a messier history than\nmerging, so use it selectively when you truly need specific commits rather than\nwhole branches.\n",2,{"_11":83,"_13":84,"_15":85,"_17":79,"_19":83,"_20":86,"_22":87},"git clone","Create a local copy of a remote Git repository, downloading all commits, branches, and files so you can start working on the project.","git-clone","\nYou've found a repository on GitHub you want to work on, or your team just\ncreated a new project and you need a local copy. `git clone` downloads an entire\nrepository from a remote server to your machine, creating a complete working\ncopy with all commits, branches, and history. It's the starting point for\ncontributing to any Git project that lives remotely.\n\nThe basic syntax is `git clone https://github.com/user/repository.git`, which\ncreates a new directory named after the repository, downloads all the data, and\nchecks out the default branch (usually main). You can specify a different\ndirectory name with `git clone https://github.com/user/repo.git my-folder`. The\nURL can be HTTPS (like the example) or SSH (`git@github.com:user/repo.git`),\ndepending on how you've configured authentication.\n\nAfter cloning, Git automatically sets up a remote called origin pointing to the\nURL you cloned from. This connection lets you fetch updates, push commits, and\nstay synchronized with the remote repository. Your local repository is a\ncomplete copy—you have all commits, tags, and history locally, not just the\nlatest version.\n\n## Shallow Clones and Performance\n\nFor very large repositories with extensive history, cloning everything can be\nslow. Running `git clone --depth 1 https://github.com/user/repo.git` creates a\nshallow clone with only the most recent commit, ignoring all history. This\ndownloads much faster and uses less disk space, which is useful for CI/CD\nenvironments where you just need the current code. The tradeoff is you can't\naccess historical commits or see the full log until you \"deepen\" the clone\nlater.\n\nYou can also clone a specific branch with\n`git clone --branch feature-name --single-branch https://github.com/user/repo.git`,\nwhich only downloads that branch's history instead of all branches. This saves\ntime in repositories with many feature branches when you only need one.\n\n## Working with Forks\n\nWhen contributing to open source projects, you typically fork the repository on\nGitHub, then clone your fork. The workflow is: fork on GitHub, clone your fork\nwith `git clone https://github.com/yourname/repo.git`, then add the original\nrepository as an upstream remote with\n`git remote add upstream https://github.com/original/repo.git`. This setup lets\nyou push to your fork while pulling updates from the original project.\n\nUnderstanding clone means understanding that you're creating a full-fledged\nrepository, not just downloading files. You can make commits, create branches,\nand work offline. The repository is yours to modify, with origin tracking where\nit came from so you can sync changes later. Cloning is usually a one-time\noperation per project—you clone once, then use fetch and pull to stay updated.\n",3,{"_11":89,"_13":90,"_15":91,"_17":79,"_19":89,"_20":92,"_22":23},"git fetch","Download commits, branches, and tags from a remote repository without automatically merging them into your work.","git-fetch","\nYour teammate just pushed new commits to the remote repository, and you want to\nsee what changed without immediately merging those changes into your current\nwork. `git fetch` downloads new commits, branches, and tags from the remote\nrepository, updating your local copy of the remote's state without touching your\nworking directory or current branch. It's the safe way to check what's new\nbefore deciding how to integrate it.\n\nWhen you run `git fetch`, Git contacts the remote repository (usually called\norigin) and downloads any commits you don't have yet. These commits go into\nremote-tracking branches like `origin/main` or `origin/feature-branch`, which\nrepresent the remote's branches on your local machine. Your actual local\nbranches—main, feature-branch, etc.—remain unchanged. This separation lets you\nreview what's new before deciding whether to merge or rebase.\n\nAfter fetching, you can examine the new commits with `git log origin/main` to\nsee what your teammates pushed, or `git diff main..origin/main` to see how your\nlocal main differs from the remote version. If you like what you see, you can\nmerge with `git merge origin/main` or rebase with `git rebase origin/main`. If\nyou don't, you can wait and fetch again later when you're ready. This two-step\nprocess (fetch then merge) gives you more control than `git pull`, which fetches\nand merges in one command.\n\n## Fetching Specific Branches and Remotes\n\nBy default, `git fetch` downloads from the remote your current branch tracks,\nbut you can specify a remote explicitly: `git fetch origin`. If you have\nmultiple remotes (like origin and upstream for forked repositories), you can\nfetch from a specific one. To fetch from all configured remotes at once, use\n`git fetch --all`.\n\nYou can also fetch a specific branch with `git fetch origin branch-name`, which\nonly downloads that branch's commits instead of everything. This saves time and\nbandwidth in large repositories with many active branches when you only care\nabout one specific branch.\n\n## Pruning Stale References\n\nOver time, branches get deleted from the remote after PRs merge, but your local\nrepository keeps references to those deleted remote branches. Running\n`git fetch --prune` removes these stale references, cleaning up your view of\nwhat exists on the remote. Many developers configure Git to always prune when\nfetching with `git config fetch.prune true`, so deleted remote branches\nautomatically disappear from their local remote-tracking branches.\n\n## Pull Request Workflows\n\nIn pull request workflows, fetch is essential for reviewing other people's code\nlocally. When someone opens a PR, you fetch to download their branch, then check\nit out to test it on your machine. The workflow looks like `git fetch origin`,\nthen `git checkout feature-branch`, which creates a local branch tracking the\nremote one. Now you can run the code, test it, and verify it works as claimed.\n\nFetch also helps you stay aware of changes without disrupting your current work.\nYou can fetch periodically throughout the day to download new commits, then\nreview what's new when convenient. This is safer than pulling, which would\nimmediately merge changes into your current branch possibly at an inconvenient\ntime.\n\nWhen working on a long-running feature branch, fetching main regularly helps you\nstay aware of how far your branch has diverged. After fetching,\n`git log HEAD..origin/main` shows commits that were added to main while you've\nbeen working. You can decide when to merge or rebase those changes into your\nfeature branch, rather than discovering a huge divergence when you try to open\nyour PR.\n\n## Tags and Releases\n\nFetch also downloads tags from the remote. When maintainers create release tags\nlike v1.0.0, those tags don't appear in your local repository until you fetch.\nRunning `git fetch --tags` specifically fetches all tags without fetching\ncommits, which is useful if you just want to see what versions have been\nreleased.\n\nUnderstanding fetch means understanding the distinction between remote\nrepositories and remote-tracking branches. The remote repository lives on GitHub\nor another server. Remote-tracking branches are your local mirror of the\nremote's branch pointers, updated only when you fetch. Your local branches are\nyour actual working branches, independent of the remote until you explicitly\nmerge or push. Fetch updates the middle layer—the remote-tracking\nbranches—giving you visibility into the remote without affecting your work.\n",{"_11":94,"_13":95,"_15":96,"_17":79,"_19":94,"_20":97,"_22":87},"git rebase","Reapply your commits on top of another branch to create a clean, linear history without merge commits for easier code review.","git-rebase","\nYou're working on a feature branch that's gotten out of sync with main. Rather\nthan creating a messy merge commit, you want to replay your changes on top of\nthe latest code. That's when you reach for `git rebase`—it rewrites your\nbranch's history to make it look like you started working from the current state\nof main.\n\nRunning `git rebase main` while on your feature branch takes your commits and\nreapplies them one by one on top of main's latest commit. Git temporarily\nremoves your commits, fast-forwards your branch to match main, then replays each\nof your commits in order. The result is a linear history where your feature work\nappears to have been built on the current main, even though you actually started\nfrom an older version.\n\nThe key difference from merge is that rebase changes commit SHAs—each replayed\ncommit gets a new identifier because its parent commit changed. This rewriting\nof history is powerful but means you shouldn't rebase commits you've already\npushed to a shared branch where others might have based work on them. Rebase is\nsafest on feature branches that only you work on.\n\n## Interactive Rebase for History Editing\n\nThe real power of rebase comes with the interactive mode:\n`git rebase -i HEAD~5`. This opens an editor showing your last five commits with\noptions to pick (keep), reword (change message), edit (modify content), squash\n(combine with previous), fixup (squash without editing message), or drop\n(delete). This lets you clean up your commit history before pushing or opening a\npull request.\n\nA common workflow is making many small commits while developing (\"WIP fix test,\"\n\"fix typo,\" \"actually fix test\"), then using interactive rebase to squash them\ninto coherent commits before sharing your work. Reviewers see a clean history\nlike \"Add user authentication\" and \"Add password reset\" instead of your messy\ndevelopment process.\n\n## Handling Conflicts During Rebase\n\nWhen rebasing, conflicts can occur if your changes and the new base both\nmodified the same code. Git stops and asks you to resolve conflicts just like\nwith merge. After fixing conflicts and staging the files, you continue with\n`git rebase --continue`. If you get stuck or decide rebasing was a mistake,\n`git rebase --abort` cancels the operation and returns your branch to its\noriginal state.\n\nIn pull request workflows, rebasing before pushing creates cleaner PRs. Instead\nof merge commits from syncing with main, your PR shows just your feature commits\nin a linear sequence. Many teams prefer this because it makes code review easier\nand keeps the main branch history readable. After your PR is approved, the merge\ncreates a single integration point in main's history.\n\nUnderstanding rebase means understanding that it's a history rewriting tool.\nYou're not just moving commits—you're recreating them. This creates clean,\nlinear histories perfect for pull requests, but requires care when working with\nshared branches.\n",{"_11":99,"_13":100,"_15":101,"_17":79,"_19":99,"_20":102,"_22":81},"git remote","Manage named connections to remote repositories, controlling where you push, fetch, and pull code from across multiple origins.","git-remote","\nYour local Git repository can track multiple remote repositories—the main\nproject on GitHub, your personal fork, a staging server, or your teammate's\nfork. `git remote` manages these connections, letting you add, remove, rename,\nand inspect the remote repositories your local repo knows about.\n\nRunning `git remote` with no arguments lists your configured remotes by name.\nMost repositories have at least one remote called origin, which is automatically\ncreated when you clone. Running `git remote -v` shows more detail, displaying\nthe URLs for fetching and pushing for each remote.\n\nTo add a new remote, use `git remote add name url`. For example, when working\nwith forks, you might add the original repository as upstream with\n`git remote add upstream https://github.com/original/repo.git`. Now you can\nfetch updates from upstream while pushing to your origin fork. Multiple remotes\nlet you pull from one place and push to another, or collaborate with multiple\nrepositories simultaneously.\n\nRemoving remotes uses `git remote remove name`, and renaming them uses\n`git remote rename old-name new-name`. These operations only affect your local\nconfiguration—they don't touch the remote repositories themselves, just your\nlocal references to them.\n\nUnderstanding remotes means understanding that Git is decentralized. Your local\nrepository is independent, and remotes are simply saved references to other\nrepositories you want to sync with. You control which remotes exist and how you\nuse them.\n",{"_11":104,"_13":105,"_15":106,"_17":79,"_19":104,"_20":107,"_22":87},"git reset","Move the current branch pointer to a different commit, unstaging files or undoing commits depending on the mode.","git-reset","\nYou've staged files for commit but realize you want to unstage them, or you've\nmade commits locally that you want to undo before pushing. `git reset` moves\nyour branch pointer and optionally modifies the staging area and working\ndirectory, giving you control over the relationship between these three states\nof your repository.\n\nThe most common use is unstaging files. After running `git add` on several\nfiles, you decide one of them shouldn't be in the next commit. Running\n`git reset filename.js` unstages that file while keeping your changes in the\nworking directory. This is safer than `git checkout -- filename.js`, which\ndiscards changes entirely.\n\nTo unstage everything you've staged, use `git reset` with no arguments. This is\nthe inverse of `git add .`—it clears the staging area while preserving all your\nfile modifications. Your work isn't lost; it's just not staged anymore.\n\n## Reset Modes and Commit Management\n\nWhen resetting to a specific commit, the mode determines what happens to your\nworking directory and staging area. The three modes are:\n\n`git reset --soft abc123` moves your branch pointer to commit abc123 but leaves\nyour staging area and working directory unchanged. Commits after abc123\ndisappear from your branch history, but their changes remain staged, ready to\ncommit again. This is useful for rewriting commit messages or combining several\ncommits into one.\n\n`git reset --mixed abc123` (the default when you don't specify a mode) moves the\nbranch pointer and unstages changes, but keeps your working directory intact.\nChanges from undone commits remain as uncommitted modifications. Use this when\nyou want to redo commits differently but keep the work.\n\n`git reset --hard abc123` moves the branch pointer, clears the staging area, and\nresets the working directory to match commit abc123. This discards all changes\nafter that commit—both committed and uncommitted. It's powerful but dangerous\nsince it destroys work. Only use hard reset when you're certain you want to\nthrow away changes.\n\n## Common Scenarios\n\nA frequent scenario is undoing the last commit: `git reset HEAD~1` moves back\none commit, putting those changes back in your working directory (with\n`--mixed`) or staging area (with `--soft`). This is less extreme than\n`git commit --amend` because it completely removes the commit rather than\nreplacing it.\n\nWhen you've committed to the wrong branch, reset helps fix it. If you\naccidentally committed to main instead of a feature branch, you can create the\nfeature branch, then reset main back before the commit: `git checkout main`,\n`git reset --hard HEAD~1`, `git checkout feature-branch` (which has the commit\nbecause you created it after committing).\n\n## Pull Request Safety\n\nNever use reset on commits you've already pushed to a shared branch where others\nmight have based work on them. Reset rewrites history by moving the branch\npointer, which causes problems for collaborators who have those commits. On your\npersonal feature branches that only you work on, reset is safe and useful for\ncleaning up before pushing.\n\nIf you reset too far or reset --hard by mistake, `git reflog` shows where your\nbranch pointer has been, letting you reset back to where you were. The commits\naren't truly deleted immediately—Git keeps them for a while in the reflog,\ngiving you a chance to recover from mistakes.\n\nUnderstanding reset means understanding Git's three trees: HEAD (current branch\npointer), index (staging area), and working directory. Reset moves HEAD and\noptionally resets the other two to match, giving you precise control over the\nstate of your repository. The key is choosing the right mode for what you want\nto achieve and being extremely careful with `--hard`.\n",{"_11":109,"_13":110,"_15":111,"_17":79,"_19":109,"_20":112,"_22":81},"git show","Display detailed information about commits, tags, or other Git objects, showing the exact diff and metadata of what changed.","git-show","\nYou want to see exactly what changed in a specific commit, or examine a tag's\ndetails, or review the content of a file at a particular point in history.\n`git show` displays detailed information about Git objects—commits, tags, trees,\nor blobs—making it the go-to command for inspecting specific points in your\nrepository's history.\n\nRunning `git show` without arguments shows the most recent commit with its\nmetadata (author, date, message) and the full diff of what changed. It's like\ncombining `git log -1` and `git diff` for the latest commit. To see a specific\ncommit, use its SHA: `git show abc123` displays that commit's details and\nchanges.\n\nYou can show specific files from a commit with\n`git show abc123:path/to/file.js`, which outputs the file's content as it\nexisted in that commit. This is useful when you want to see what a file looked\nlike at a specific point without checking out that commit. You can redirect this\nto a file with `git show abc123:old-file.js > recovered-file.js` to recover\ndeleted files or old versions.\n\nWhen examining tags, `git show v1.0.0` displays the tag object's metadata (if\nit's an annotated tag) or the commit it points to (if it's a lightweight tag).\nThis is how you see release notes or verify what version a tag represents.\n\nIn pull request workflows, show helps you review individual commits during code\nreview. When someone's PR has ten commits and you want to understand what each\none did, you can `git show` each commit hash to see its isolated changes. This\nis often clearer than looking at the full branch diff because it shows the\nlogical progression of work.\n\nUnderstanding show means having a quick way to inspect any Git object. It's the\ncommand for \"show me what this is\" when you have a SHA, tag name, or file\nreference and want to see the details.\n",{"_11":114,"_13":115,"_15":116,"_17":79,"_19":114,"_20":117,"_22":87},"git stash","Temporarily save uncommitted changes to a stack and restore them later, letting you switch branches with a clean working directory.","git-stash","\nYou're in the middle of working on a feature when an urgent bug report comes in.\nYou need to switch branches immediately, but you're not ready to commit your\nhalf-finished work. `git stash` saves your uncommitted changes temporarily,\ngiving you a clean working directory so you can switch branches, then lets you\nrestore those changes later.\n\nRunning `git stash` takes all your modified tracked files and staged changes,\nsaves them to a stack, and reverts your working directory to match the last\ncommit. Now you can switch branches, pull updates, or do whatever you need with\na clean slate. When you're ready to continue your original work, `git stash pop`\nrestores the most recent stash and removes it from the stack.\n\nYou can stash multiple times, building up a stack of saved changes. Running\n`git stash list` shows all your stashes with identifiers like `stash@{0}` (most\nrecent), `stash@{1}`, etc. To restore a specific stash, use\n`git stash apply stash@{1}`. The difference between pop and apply is that pop\nremoves the stash after applying, while apply keeps it for potential reuse.\n\nAdding a message makes stashes easier to identify:\n`git stash save \"WIP: user authentication\"` or\n`git stash push -m \"half-done API changes\"`. Later, `git stash list` shows your\nmessage alongside each stash, helping you remember what work each one contains.\n\n## Stashing Untracked and Ignored Files\n\nBy default, stash only saves tracked files (files Git already knows about). New\nfiles you created but haven't added yet stay in your working directory. To stash\nthose too, use `git stash -u` (or `--include-untracked`). To stash everything\nincluding ignored files, use `git stash -a` (or `--all`), though this is rare\nsince you usually don't want temporary build artifacts in stashes.\n\nIf you realize you don't need a stash anymore, `git stash drop` deletes the most\nrecent one, or `git stash drop stash@{2}` deletes a specific stash. To clear all\nstashes, use `git stash clear`, though be careful—deleted stashes are hard to\nrecover.\n\n## Pull Request Context\n\nIn pull request workflows, stashing is common when switching context. You're\nworking on your feature branch when you need to quickly review someone's PR. You\nstash your changes, check out their branch, test it, leave review comments, then\nswitch back to your branch and pop your stash to continue where you left off.\n\nStashing also helps when pulling causes conflicts you're not ready to handle. If\nyou pull and get conflicts, you can `git merge --abort`, stash your changes,\npull cleanly, then apply your stash and resolve conflicts in a more controlled\nway.\n\nUnderstanding stash means having a temporary parking spot for work in progress.\nIt's not a replacement for commits—stashed changes aren't part of your\nrepository history and can be lost if you're not careful. Use stash for\nshort-term storage when switching contexts, then commit properly when you're\nready to save work permanently.\n","Commands for collaborating with teammates and managing pull request workflows.","Collaboration & PR Workflow",{"_8":121,"_13":158,"_71":159,"_17":126},[122,128,133,138,143,148,153],{"_11":123,"_13":124,"_15":125,"_17":126,"_19":123,"_20":127,"_22":81},"git bisect","Use binary search through commit history to efficiently find which commit introduced a bug or regression in your codebase.","git-bisect","tier-3","\nTests are failing, but they worked fine last week. Somewhere in the past 50\ncommits, someone introduced a bug. Manually checking each commit would take\nhours. `git bisect` automates the search using binary search, cutting the\nproblem space in half with each test until it identifies the exact commit that\nbroke things.\n\nYou start by running `git bisect start`, then mark your current commit as bad\n(where the bug exists) with `git bisect bad`. Next, identify a commit where\nthings worked—maybe last week's release—and mark it good with\n`git bisect good v1.2.0`. Git checks out a commit halfway between good and bad.\nYou test whether the bug exists at this commit, then run `git bisect good` or\n`git bisect bad` based on your findings.\n\nGit repeats this process, each time narrowing the range by half. After a few\niterations (log₂ of your commit count), Git identifies the first bad commit—the\none that introduced the bug. Running `git bisect reset` returns you to your\noriginal branch.\n\nFor automated testing, you can run `git bisect run ./test-script.sh`, where the\nscript exits with 0 for good commits and non-zero for bad ones. Git\nautomatically bisects through commits, running the script each time, and tells\nyou which commit is the culprit without manual intervention.\n\nIn pull request workflows, bisect helps investigate regressions reported after\nmerging. When a feature causes unexpected behavior, bisect pinpoints which PR or\ncommit introduced the issue, even if the problem wasn't noticed until later.\nThis is far more efficient than reading through dozens of commits trying to spot\nthe bug.\n\nUnderstanding bisect means having a systematic debugging tool for when you know\nsomething broke but not when or how. It transforms a potentially hours-long\nsearch into a few minutes of binary search, leveraging your commit history to\nisolate problems.\n",{"_11":129,"_13":130,"_15":131,"_17":126,"_19":129,"_20":132,"_22":81},"git blame","Show which commit and author last modified each line of a file, helping you track down when and why specific changes were made.","git-blame","\nYou're looking at a confusing piece of code and wondering who wrote it and why.\n`git blame` shows which commit last modified each line of a file, displaying the\ncommit SHA, author, date, and line content. Despite the name, it's not about\nassigning fault—it's about finding context for code by connecting it to the\ncommit and author who can explain it.\n\nRunning `git blame filename.js` displays the file with annotations showing who\nlast touched each line. If line 42 was added in commit abc123 by Alice on March\n15, that information appears next to the line. This helps you understand the\nhistory of specific code sections and find the right person to ask questions.\n\nThe `-L` flag limits blame to specific line ranges: `git blame -L 10,20 file.js`\nshows only lines 10 through 20. This narrows the output when you're\ninvestigating a particular function or block of code. You can also use function\nnames with some languages: `git blame -L :functionName file.js`.\n\nAdding `-w` ignores whitespace changes, so reformatting doesn't obscure who made\nsubstantive changes: `git blame -w file.js`. The `-C` flag detects code moved or\ncopied from other files, showing where the code originally came from rather than\njust who moved it.\n\nIn pull request workflows, blame helps during code review when you need more\ncontext about existing code. If a PR modifies a function and you're unsure about\nits original purpose, blame shows the commit that added it. You can then use\n`git show` on that commit to see the full change and commit message explaining\nwhy it was written that way.\n\nUnderstanding blame means having a tool to answer \"why is this code here?\" by\nfinding the commit that introduced it. The commit message and surrounding\nchanges provide context that helps you make informed decisions when modifying\ncode or investigating bugs.\n",{"_11":134,"_13":135,"_15":136,"_17":126,"_19":134,"_20":137,"_22":81},"git clean","Remove untracked files and directories from your working directory, cleaning up build artifacts and temporary files.","git-clean","\nYour working directory is cluttered with build artifacts, temporary files, and\nother untracked junk that you want to delete. `git clean` removes untracked\nfiles (files Git doesn't know about), giving you a pristine working directory\nthat matches what's in version control.\n\nBecause clean permanently deletes files, Git requires the `-f` (force) flag to\nactually remove anything. Running `git clean -f` deletes untracked files in the\ncurrent directory. To also remove untracked directories, add `-d`:\n`git clean -fd`. This is common after builds or tests that create temporary\ndirectories.\n\nBefore deleting anything, run `git clean -n` (dry run) to see what would be\nremoved. This safety check prevents accidentally deleting files you meant to\nkeep. If the list looks right, run the same command with `-f` instead of `-n` to\nactually delete them.\n\nBy default, clean respects `.gitignore` and won't remove ignored files. To also\nremove ignored files (like build artifacts explicitly ignored), use `-x`:\n`git clean -fdx`. This is useful when you want to completely reset your working\ndirectory to a clean state, removing everything that isn't tracked.\n\nInteractive mode with `-i` prompts you for each file or directory, letting you\nselect what to delete. This is safer than force-deleting everything at once,\ngiving you fine-grained control over what stays and what goes.\n\nIn pull request workflows, clean helps when switching between branches with very\ndifferent build outputs or generated files. After checking out a different\nbranch, clean removes files that don't exist in that branch's version,\npreventing old build artifacts from interfering with tests or causing confusion.\n\nUnderstanding clean means knowing how to remove untracked files safely. It's a\npowerful cleanup tool, but its destructive nature requires caution. Always\ndry-run first, and make sure you're not about to delete work in progress that\njust isn't tracked yet.\n",{"_11":139,"_13":140,"_15":141,"_17":126,"_19":139,"_20":142,"_22":81},"git reflog","View the reference log of where your branch pointers have been, helping you recover lost commits and undo mistakes like bad rebases.","git-reflog","\nYou just ran `git reset --hard` and immediately regretted it, or you\naccidentally deleted a branch that had important commits. `git reflog` is your\nsafety net, showing a log of where your HEAD and branch pointers have been, even\nfor commits that are no longer reachable from any branch.\n\nRunning `git reflog` displays a chronological list of every position HEAD has\npointed to: commits, checkouts, resets, merges, rebases—everything. Each entry\nshows the commit SHA, the action that moved HEAD there, and how many steps back\nit is (HEAD@{0} is current, HEAD@{1} is one step back, etc.). This history is\nlocal to your repository and isn't shared when you push.\n\nIf you reset to the wrong commit, reflog shows where you were before. Say you\nwere at commit abc123, ran `git reset --hard def456` by mistake, and want to get\nback. Running `git reflog` shows abc123 in the history, and you can return with\n`git reset --hard abc123`. You've essentially undone your reset by resetting to\nwhere you were before.\n\nDeleted branches can be recovered the same way. If you deleted feature-branch\nwith `git branch -D feature-branch`, reflog shows where that branch pointed.\nCreate a new branch at that commit with `git checkout -b feature-branch abc123`,\nand you've recovered the deleted branch.\n\nThe reflog expires after 90 days by default (30 days for unreachable commits),\nso it's not permanent. But for recent mistakes, it's an incredibly powerful undo\nmechanism. It's specific to your local repository—if you clone fresh, you start\nwith an empty reflog.\n\nEach branch has its own reflog, accessed with `git reflog branch-name`. This\nshows the history of that specific branch pointer, which can be useful when\ndebugging complex branch manipulations.\n\nUnderstanding reflog means understanding that Git rarely deletes commits\nimmediately. When you reset, rebase, or delete branches, the commits still\nexist—they're just not reachable from any reference. Reflog gives you a way to\nfind those commits and recover them before Git's garbage collection eventually\nremoves them.\n",{"_11":144,"_13":145,"_15":146,"_17":126,"_19":144,"_20":147,"_22":81},"git revert","Safely undo one or more commits by creating new commits that reverse their changes, preserving the full project history.","git-revert","\nA commit introduced a bug that made it to production, and you need to undo it\nimmediately. Unlike `git reset`, which rewrites history, `git revert` creates a\nnew commit that undoes a previous commit's changes while preserving the complete\nhistory. This makes it safe to use on shared branches like main where rewriting\nhistory would cause problems for your team.\n\nRunning `git revert abc123` examines what changes that commit introduced, then\ncreates a new commit that reverses those changes. If the original commit added a\nfunction, the revert commit removes it. If it modified a file, the revert undoes\nthose modifications. The result is that the code looks like the original commit\nnever happened, but both the original and the revert remain in history.\n\nYou can revert multiple commits with `git revert abc123 def456`, or a range with\n`git revert abc123..def456`. Each reverted commit gets its own revert commit,\nmaintaining a clear record of what was undone and when. If you want to revert\nseveral commits but create only one revert commit, use\n`git revert -n abc123 def456` (the `-n` flag means no commit), make any\nadditional changes, then commit manually.\n\nWhen reverting creates conflicts—because the code has changed significantly\nsince the original commit—Git stops and asks you to resolve them. After\nresolving and staging files, `git revert --continue` creates the revert commit.\nIf you decide reverting is too complicated, `git revert --abort` cancels the\noperation.\n\nIn pull request workflows, revert is how you safely undo merged PRs. If a\nfeature causes problems in production, you can revert the merge commit to\nquickly roll back, then investigate the issue at your own pace. The revert\ncommit can be merged immediately for a quick fix, while you work on properly\naddressing the bug in a new PR. Some teams even create \"revert PRs\" to track the\nrollback through code review.\n\nUnderstanding revert means having a safe undo button for commits on shared\nbranches. It doesn't erase history—it adds to it with commits that reverse\nprevious work. This transparency is valuable for understanding what happened and\nwhy, especially when debugging or conducting post-mortems on production issues.\n",{"_11":149,"_13":150,"_15":151,"_17":126,"_19":149,"_20":152,"_22":81},"git tag","Create, list, and manage tags to mark specific commits as important milestones like releases or version numbers in your repository.","git-tag","\nYou've just finished version 1.0 of your project and want to mark this exact\ncommit as the release. `git tag` creates a labeled reference to a specific\ncommit, giving you a human-readable name for important points in your history.\nTags are commonly used for version releases like v1.0.0, v2.1.3, or stable\ncheckpoints in development.\n\nRunning `git tag v1.0.0` creates a lightweight tag pointing to your current\ncommit. This is simply a named reference—a pointer to a commit that doesn't\nchange. To see all tags, run `git tag` with no arguments. Tags are permanent\nmarkers that make it easy to check out specific versions later with\n`git checkout v1.0.0`.\n\nAnnotated tags store additional metadata:\n`git tag -a v1.0.0 -m \"First stable release\"` creates a tag object with the\ncreator's name, date, and message. These are recommended for releases because\nthey capture more information about why the tag was created. You can see an\nannotated tag's details with `git show v1.0.0`.\n\nTo tag an older commit, specify its SHA:\n`git tag -a v0.9.0 abc123 -m \"Beta release\"`. This is useful when you forgot to\ntag a release at the time or need to retroactively mark commits.\n\nBy default, `git push` doesn't upload tags. To push tags to the remote, use\n`git push origin v1.0.0` for a specific tag or `git push --tags` for all tags.\nDeleting tags requires `git tag -d v1.0.0` locally and\n`git push origin --delete v1.0.0` on the remote.\n\nIn pull request workflows and CI/CD systems, pushing version tags often triggers\ndeployment pipelines or GitHub releases. Teams use semantic versioning (v1.2.3)\nwhere the numbers indicate major.minor.patch versions, and tags mark each\nrelease for easy reference and rollback if needed.\n",{"_11":154,"_13":155,"_15":156,"_17":126,"_19":154,"_20":157,"_22":87},"git worktree","Work on multiple branches simultaneously by creating additional working directories linked to the same repository.","git-worktree","\nYou're deep into work on a feature branch when an urgent bug fix lands on your\nplate. Normally you'd stash your changes, switch branches, fix the bug, then\nswitch back. But what if you could keep both branches active at the same time in\nseparate directories? `git worktree` lets you check out multiple branches\nsimultaneously, each in its own directory, all connected to the same repository.\n\nRunning `git worktree add ../hotfix main` creates a new directory alongside your\ncurrent one, with main checked out and ready for work. You can make commits in\nthe hotfix directory while your original directory stays on your feature branch.\nBoth directories share the same repository history and configuration—commits\nmade in either show up when you run `git log` in both.\n\nThis is perfect for urgent fixes that interrupt feature work. Instead of\nstashing and context-switching, you keep your feature branch as-is, work on the\nhotfix in a separate directory, test both simultaneously, and merge the fix\nwithout disturbing your in-progress feature. Running builds or tests in parallel\nacross branches becomes trivial.\n\nTo create a worktree with a new branch, use\n`git worktree add -b new-branch ../new-branch`. This creates the directory,\ncreates the branch, and checks it out there. Listing worktrees with\n`git worktree list` shows all active working trees and which branches they have\nchecked out.\n\nWhen you're done with a worktree, remove the directory and clean up with\n`git worktree remove ../hotfix`. This tells Git the worktree no longer exists.\nIf you just delete the directory without using worktree remove, run\n`git worktree prune` to clean up Git's tracking.\n\nOne branch can only be checked out in one worktree at a time, preventing\nconflicts from simultaneous edits in different locations. If you try to create a\nworktree with a branch that's already checked out elsewhere, Git refuses unless\nyou force it with `--detach`.\n\nIn pull request workflows, worktrees let you review PRs in separate directories\nwhile continuing your own work. Check out the PR branch in a worktree, run the\ncode, test it, and leave feedback, all without touching your main working\ndirectory. You can even compare builds side-by-side.\n\nUnderstanding worktrees means escaping the limitation of one working directory\nper repository. It's multiple checkouts of the same repository, sharing history\nand configuration but with independent working directories. This is cleaner than\ncloning the repository multiple times and more flexible than constantly stashing\nand switching.\n","Advanced commands for complex Git operations and debugging.","Advanced Workflow Commands",{"_8":161,"_13":188,"_71":189,"_17":166},[162,168,173,178,183],{"_11":163,"_13":164,"_15":165,"_17":166,"_19":163,"_20":167,"_22":81},"git config","Configure Git settings at global, repository, or system level to customize your workflow, identity, and default behaviors.","git-config","tier-4","\nGit needs to know who you are when you make commits, and you want to customize\nhow it behaves. `git config` sets configuration values that control everything\nfrom your identity to default branch names to merge strategies. These settings\nlive at three levels: system (all users), global (your user account), and local\n(specific repository).\n\nThe first thing you configure after installing Git is your identity:\n`git config --global user.name \"Your Name\"` and\n`git config --global user.email \"your@email.com\"`. These values appear in every\ncommit you make. Using `--global` sets them for all repositories on your\nmachine. Omit `--global` to set them only for the current repository, which is\nuseful if you use different emails for work and personal projects.\n\nTo see all your current settings, run `git config --list`. For a specific value,\nuse `git config user.name`. To change a value, use `git config `.\nTo remove a value, use `git config --unset `.\n\nCommon configurations include setting your default editor\n(`git config --global core.editor vim`), configuring line ending handling\n(`git config --global core.autocrlf true`), and setting the default branch name\nfor new repositories (`git config --global init.defaultBranch main`).\n\nYou can create aliases for frequently used commands:\n`git config --global alias.co checkout` lets you type `git co` instead of\n`git checkout`. More complex aliases can combine multiple commands:\n`git config --global alias.lg \"log --graph --oneline --all\"` creates a custom\nlog format.\n\nConfiguration files live in `.git/config` (repository level), `~/.gitconfig`\n(global level), or system paths (system level). You can edit these files\ndirectly instead of using `git config` commands, though using the command is\nsafer as it validates syntax.\n\nUnderstanding config means customizing Git to match your workflow. Settings\ncontrol how Git behaves, from simple preferences like colors and aliases to\ncritical settings like merge strategies and credential storage. Taking time to\nconfigure Git properly makes daily work smoother.\n",{"_11":169,"_13":170,"_15":171,"_17":166,"_19":169,"_20":172,"_22":81},"git grep","Search for text patterns across tracked files in your repository, faster and more Git-aware than regular grep.","git-grep","\nYou need to find where a specific function is called across your entire\ncodebase, or search for a configuration variable that might appear in several\nfiles. `git grep` searches through files tracked by Git, finding patterns much\nfaster than standard grep because it only searches tracked files and leverages\nGit's internal data structures.\n\nRunning `git grep \"searchPattern\"` searches for the pattern in all tracked files\nin your working directory. It shows matching lines with the filename and line\nnumber, making it easy to locate results. Unlike regular grep, it automatically\nignores untracked files, build artifacts, and anything in `.gitignore`, focusing\non actual source code.\n\nAdding `-n` shows line numbers, which is often default in many configurations.\nThe `-i` flag makes the search case-insensitive: `git grep -i \"TODO\"` finds\n\"todo,\" \"TODO,\" and \"ToDo.\" The `-w` flag matches whole words only:\n`git grep -w \"log\"` finds \"log\" but not \"login\" or \"dialog.\"\n\nYou can search in specific paths or files: `git grep \"pattern\" -- src/` searches\nonly in the src directory. To search in a specific commit or branch, add the\nreference: `git grep \"pattern\" main` searches in the main branch, while\n`git grep \"pattern\" abc123` searches in a specific commit.\n\nThe `-c` flag counts matches per file instead of showing lines:\n`git grep -c \"TODO\"` shows how many TODOs exist in each file. The `-l` flag\nlists only filenames with matches, without showing the matching lines\nthemselves.\n\nFor more advanced searches, `-E` enables extended regular expressions:\n`git grep -E \"function\\s+\\w+\"` finds function declarations. The `--and`, `--or`,\nand `--not` flags let you combine patterns:\n`git grep --all-match -e pattern1 -e pattern2` finds lines matching both\npatterns.\n\nIn pull request workflows, git grep helps reviewers understand how code is used\nacross the codebase. If a PR modifies a utility function, you can grep for its\nusage to see what might be affected. This is faster than IDE search in large\nrepositories and works on servers or in CI environments without a full IDE\nsetup.\n\nUnderstanding git grep means having a fast, Git-aware search tool that respects\nyour repository structure and ignores noise. It's optimized for finding code,\nmaking it the right tool for locating functions, variables, TODOs, or any text\npattern in your source files.\n",{"_11":174,"_13":175,"_15":176,"_17":166,"_19":174,"_20":177,"_22":81},"git mv","Move or rename files and directories while preserving their full Git history, keeping the index updated with the relocation.","git-mv","\nYou need to rename a file or move it to a different directory, and you want Git\nto track that it's the same file in a new location rather than treating it as a\ndeletion and a new file. `git mv` moves or renames files while automatically\nstaging the change, making it the Git-aware way to reorganize your codebase.\n\nRunning `git mv old-name.js new-name.js` renames the file and stages both the\ndeletion of the old name and the addition of the new name as a single operation.\nGit tracks this as a rename, preserving the file's history across the name\nchange. You can view the file's complete history including pre-rename commits\nwith `git log --follow new-name.js`.\n\nMoving files to different directories works the same way:\n`git mv src/utils.js src/helpers/utils.js` moves the file and stages the change.\nYou can even move and rename simultaneously:\n`git mv old-name.js src/new-name.js`.\n\nTechnically, you could rename files manually and then `git rm old-name.js` and\n`git add new-name.js`, but `git mv` does this in one step and makes the\nintention clearer. Git's rename detection usually figures it out either way, but\nusing `git mv` is more explicit and slightly more reliable.\n\nAfter running `git mv`, the change is staged and ready to commit. Including\nrenamed files in commits with other logical changes (like updating imports to\nuse the new path) keeps the history coherent.\n\nIn pull request workflows, renaming and moving files can make reviews\nchallenging because reviewers see large diffs. GitHub and similar platforms have\nrename detection that shows \"renamed: old-name.js → new-name.js\" instead of\nshowing the entire file as deleted and re-added. Using `git mv` helps these\nplatforms correctly identify renames, making reviews clearer.\n\nUnderstanding git mv means keeping Git aware of file reorganization. Instead of\ntreating moves and renames as unrelated deletions and additions, Git sees the\ncontinuity, preserving history and making it easier to track how files evolved\neven as they moved around the repository.\n",{"_11":179,"_13":180,"_15":181,"_17":166,"_19":179,"_20":182,"_22":81},"git rm","Remove files from both your working directory and Git tracking, or stop tracking files while keeping them on disk with the cached option.","git-rm","\nYou no longer need a file in your repository and want to delete it from version\ncontrol. `git rm` removes the file from both your working directory and the\nstaging area, preparing the deletion for your next commit. It's Git's way of\ndeleting files while keeping the repository aware of the change.\n\nRunning `git rm filename.js` deletes the file from your filesystem and stages\nthe deletion. Your next commit will record that the file was removed. This is\ncleaner than manually deleting the file and then running `git add`, though both\napproaches work.\n\nIf you've modified the file since the last commit and haven't staged those\nchanges, Git refuses to remove it (protecting you from accidentally losing\nwork). Use `-f` to force removal: `git rm -f modified-file.js`. Be careful with\nthis—the file and its uncommitted changes are gone.\n\nSometimes you want to stop tracking a file without deleting it from your\nfilesystem. This happens when you accidentally committed a file that should be\nignored, like a local configuration or secrets file. Running\n`git rm --cached secrets.env` removes the file from Git tracking but leaves it\nin your working directory. After committing this change and adding the file to\n`.gitignore`, the file stays local but won't be tracked going forward.\n\nTo remove entire directories, add `-r` for recursive:\n`git rm -r old-directory/`. This removes the directory and all its contents from\nGit and your filesystem.\n\nIf you've already deleted files manually (using `rm` instead of `git rm`), Git\nnotices them as \"deleted\" in `git status`. You need to stage the deletions with\n`git add` or use `git rm` on the deleted files (which seems odd but works) to\nstage the removal. Many developers just use `git add -A` after deleting files,\nwhich catches all changes including deletions.\n\nIn pull request workflows, removing files should be deliberate and explained in\ncommit messages. If a PR deletes a module, reviewers want to understand why and\nverify nothing still depends on it. Clean deletions make codebases easier to\nmaintain by removing dead code and obsolete files.\n\nUnderstanding git rm means properly handling file deletions in Git. Instead of\nfiles mysteriously disappearing, deletions are tracked changes that appear in\ncommits, making it clear what was removed, when, and by whom.\n",{"_11":184,"_13":185,"_15":186,"_17":166,"_19":184,"_20":187,"_22":81},"git submodule","Include other Git repositories within your repository, managing external dependencies with specific versions.","git-submodule","\nYour project depends on another Git repository—maybe a shared library, a theme,\nor a vendored dependency—and you want to include it at a specific version\nwithout copying all the code. `git submodule` lets you embed one repository\ninside another, tracking a specific commit from the external repository.\n\nAdding a submodule uses\n`git submodule add https://github.com/user/library.git path/to/library`. This\nclones the external repository into the specified path and creates a\n`.gitmodules` file tracking the submodule's URL and path. Your repository stores\na reference to the specific commit of the submodule, not the submodule's code\nitself.\n\nWhen someone clones your repository, they need to initialize and update\nsubmodules with `git submodule init` and `git submodule update`, or use\n`git clone --recurse-submodules` to do it automatically. This downloads the\nsubmodule repositories at the commits referenced in your project.\n\nTo update a submodule to its latest commit, navigate into the submodule\ndirectory, pull or checkout the desired commit, then return to the parent\nrepository and commit the new submodule reference. The parent repo treats the\nsubmodule as a single \"file\" whose content is a commit SHA.\n\nRemoving submodules requires several steps:\n`git submodule deinit path/to/library`, `git rm path/to/library`, and manually\nremoving the entry from `.gitmodules` if it's the last submodule. This\ncomplexity is why many teams avoid submodules when simpler dependency management\nworks.\n\nSubmodules are powerful for managing dependencies that need exact version\ncontrol, like vendored libraries or shared components across multiple projects.\nThe tradeoff is complexity—team members need to remember to update submodules,\nand operations like `git pull` don't automatically update submodule commits.\n\nIn pull request workflows, submodule changes appear as the submodule directory\nshowing a different commit SHA. Reviewers need to understand whether the\nsubmodule update is intentional and whether it might break compatibility. Many\nteams prefer package managers (npm, pip, cargo) over submodules for this reason,\nreserving submodules for cases where they truly need to track specific commits\nof external repositories.\n\nUnderstanding submodules means managing repositories within repositories. It's a\nspecialized tool for specific use cases where you need precise version control\nof external dependencies, accepting the added complexity in exchange for that\ncontrol.\n","Specialized commands for specific use cases and configurations.","Specialized Commands","actionData","errors"]

Git Commands Reference

Essential Daily Commands

Collaboration & PR Workflow

Advanced Workflow Commands

Specialized Commands