10 Git Commands That Help Engineering Teams to Boost Productivity
Git commands help developers manage interruptions, troubleshoot regressions, and switch between tasks without losing track of their work. A developer might be halfway through a feature when a production bug requires urgent attention. Meanwhile, a teammate needs help identifying a regression, and an incomplete branch is hindering progress.
These interruptions are common in software development, but they do not have to derail progress. The right Git commands allow developers to save unfinished work, review changes before committing them, trace bugs through a project’s history, and recover commits that seem to have vanished.
For engineering leaders, the value lies not just in knowing git commands, since teams also need agreed-upon conventions for branching, reviewing changes, and handling urgent fixes. Without such conventions, even experienced developers can waste time trying to work out inconsistent workflows.
The following are 10 Git commands worth knowing, along with examples of how they are used in everyday engineering work.
1. git status: Check the state of your work
git status --shortBefore switching branches or starting a new task, check the current branch and identify uncommitted changes. The --short option provides a compact view of the working directory, helping prevent unfinished work from being overlooked.
It is especially useful when a developer has been working on multiple files and wants to determine which changes pertain to the current task.
When should I use it? Before switching branches, committing, pulling, or cleaning up after a task.
When on a team, it is advisable for developers to check the state of their working tree before they switch branches or remove files. This is a minor measure that can stop unrelated changes from being included in a commit.
2. git diff: Review changes before committing
git diffgit diff --stagedgit diff main...HEADUse these comparisons to inspect changes at different stages of development and understand what a feature branch introduces before requesting review.
Just because a build is successful doesn’t mean the change includes only the intended edits; the developer might have left debugging code in the program, altered another file, or overlooked a change when preparing the commit.
The output of git diff indicates that there are unstaged changes. In order to see the changes that are already in the staging area, you should use git diff –staged. The third command compares the current branch with main in order to help you review the changes introduced by the branch.
When should I use it? Before committing, when reviewing a teammate’s branch locally, or when checking whether a patch includes unintended edits.
As part of the normal development process, team members should carry out differential reviews, thereby enabling developers to spot any accidental changes before their code reaches a reviewer.
3. git stash: Save unfinished work temporarily
git stash push -m "WIP: checkout validation"git stash listgit stash popStash unfinished tracked-file changes when you need to switch tasks quickly. Add a descriptive message, inspect saved stashes when necessary, and restore the latest stash when you’re ready to resume. Because git stash pop removes the stash entry after a successful application, check for conflicts before continuing.
A stash temporarily shelves local changes so a developer can switch tasks without making a premature commit. Naming the stash makes it easier to recognize later, especially if a developer has several interruptions in a day. Use git stash pop to reapply the most recent stash and remove it from the stash list; use git stash apply when you want to reapply changes but keep the stash entry.
When should you use it? A production issue interrupts a feature, a developer needs to review another branch, or a quick experiment should not become a commit.
For team practices, stashes should be regarded as temporary storage rather than as backups or a means of sharing code. Developers must check the stash list and remove the entries that they no longer need.
4. git switch: Move between branches
git switch maingit switch -c feature/checkout-validationKeep features and fixes isolated in dedicated branches. This makes parallel development, code review, and change tracking easier to manage.
A developer is able to work on a feature or bug fix without having to make direct changes to the main development branch, and git switch offers a simple method of moving between branches or creating a new one.
The first command moves to main, and the second one creates a branch called feature/checkout-validation before switching to it.
When should I use it? Moving from a feature branch to a hotfix, starting a new task, or switching to a branch for review.
For team practices, use descriptive branch names that indicate the purpose of the work; agree on a naming convention so developers can identify features and fixes without opening every branch.
GitHub’s GitHub flow guide offers a useful reference for branch-based collaboration.
5. git log: Trace a project’s history
git log --oneline --graph --decorate -15Inspect the latest 15 commits in a compact graph. The output displays abbreviated commit IDs, branch and tag references, and the relationships between commits, making it easier to understand how work has progressed across branches.
If a behavior changes suddenly, the commit history can be used to find out what took place. The command mentioned above shows the 15 most recent commits in the form of a compact graph, together with references to branches and tags.
Using this view, developers will be able to observe how branches have diverged, spot recent changes, and locate commits that are worth investigating.
When should I use it? Before rebasing, during incident investigation, or when preparing a focused pull request.
For team practice, ask developers to write commit messages that explain the purpose of the change; for example, instead of writing Fix bug, they should write Handle expired checkout sessions.
6. git rebase: Bring a feature branch up to date
git fetch origingit rebase origin/mainFetching first lets developers inspect incoming changes before integrating them. Rebasing can maintain a linear project history, but coordinate with the team before rewriting commits on shared branches.
Feature branches can get out of step with the main branch when other developers merge their work into it. Rebase replays the branch’s commits on top of a new base so the feature branch can incorporate the latest changes.
The example begins by getting the updates from the remote repository before rebasing the current branch onto origin/main.
Conflicts can occur when changes overlap. After resolving them and staging the affected files, continue with:
git rebase --continuegit rebase --abortWhen conflicts interrupt a rebase, resolve the affected files, stage the fixes, and continue. If the operation should not proceed, abort it rather than leaving the repository in an unfinished state.
When should I use it? Updating a feature branch before review or bringing it up to date with the team’s integration branch.
Important caution: Since rebasing rewrites the history, avoid rebasing commits that other developers are already relying on unless the team has arranged for the change. You should follow the repository’s established conventions regarding shared branches.
See the official Git rebase documentation.
7. git cherry-pick: Move a specific fix to another branch
git cherry-pick <commit-sha>Apply the changes introduced by a specific commit to the current branch without merging the entire source branch. This is useful for targeted hotfixes and selectively moving changes between release and development branches.
There are cases in which a release branch requires a specific fix, but the remaining work on the original branch has not yet been prepared for merging. The git cherry-pick command applies the changes introduced by a chosen commit to the branch currently in use.
For instance, a developer may need to transfer a reviewed payment fix to a maintenance branch without also including several unfinished features.
When should you use it? Backporting a small, reviewed fix or moving a narrowly scoped change between branches.
For team practices, keep a record of where important fixes have been applied; if the same change needs to be applied to several release branches, monitor each instance so teams don’t lose track of which versions include it.
8. git bisect: Find the commit that introduced a bug
git bisect startgit bisect badgit bisect good <known-good-commit>Git bisect uses a binary search to narrow down the commit that introduced a regression. Mark a known-bad revision and a known-good revision, test the revisions Git selects, and mark each result as good or bad until the problematic commit is identified. Run git bisect reset when finished to leave bisect mode.
A regression might show up after dozens or hundreds of commits, and going through each change one by one can make troubleshooting time-consuming.
The binary search method is used by git bisect to reduce the range. To do this, developers have to specify a commit that is known to be faulty and one that is known to be good, after which they test the revisions that Git checks out. Each test result helps to narrow down the search until the problematic commit is found.
For a repeatable test, Git can also automate the process:
git bisect run <test-command>
When should I use it? A regression has been confirmed, but the point of introduction is unclear, and many commits have landed since the last known-good version.
For team practice, it is essential that the test reliably detects the problem; otherwise, a test that gives inconsistent results might lead the investigation down the wrong path.
9. git reflog: Recover a commit that seems lost
git reflogA reset, a rebase, or a change to a branch may make a commit seem as if it has vanished. Before carrying out another recovery operation, check the reflog.
The record of Git shows the most recent movements of references such as HEAD; these entries can be used to find a commit that is no longer visible in the current branch’s history.
Once you find the relevant commit hash, create a recovery branch:
git switch -c recovery/feature <commit-sha>It provides you with a named branch from which you can examine the commit and retain its contents.
When should I use it? A commit appears to have vanished after a reset, rebase, or branch change.
For the team, it should be taught that developers check the reflog before executing any additional destructive commands, since recovery will be easier if they don’t overwrite the state they are trying to restore.
10. git worktree: Handle two branches in separate directories
git worktree add ../project-hotfix hotfix/payment-timeoutCreate a separate working directory for a hotfix while keeping your primary checkout intact. Git worktrees are useful when urgent fixes arrive during feature development because they reduce the need to repeatedly stash work and switch branches. The target branch must not already be checked out in another worktree.
It is not always convenient to switch branches when a developer has a large amount of work still to be completed. Git worktrees enable a number of working directories to be linked with the same repository.
A developer can have a feature under development in one directory and deal with a production hotfix in another, thus avoiding the need to repeatedly stash changes or switch the main working directory back and forth.
When the additional working directory is no longer needed, remove it:
git worktree remove ../project-hotfix
When should you use it? A team frequently handles production hotfixes while developers are working on in-progress features.
Team practice: Agree on a directory naming pattern and remove unused worktrees. They are useful for parallel work, but they still require basic workspace management.
Git commands cheat sheet
| Goal | Command |
|---|---|
| Check working-tree state | git status –short |
| Review unstaged changes | git diff |
| Review staged changes | git diff –staged |
| Save local work temporarily | git stash push -m “WIP: description” |
| Switch branches | git switch <branch> |
| Create and switch to a branch | git switch -c <branch> |
| View compact commit history | git log –oneline –graph –decorate -15 |
| Update a branch with rebase | git fetch origin && git rebase origin/main |
| Apply one commit elsewhere | git cherry-pick <commit-sha> |
| Investigate a regression | git bisect start |
| Find recent reference movements | git reflog |
| Add a separate working directory | git worktree add <path> <branch> |
This Git commands cheat sheet is intended as a quick reference; the sections above explain when each command is useful and where it can be risky.
What are the five steps of Git?
A common Git workflow can be explained in five steps. Teams may use different branching and release strategies, but these core steps apply to many day-to-day code changes.
- Update your local view of the repository. Check your current branch and working-tree state. If appropriate, fetch the latest remote changes before starting.
- Create or switch to a branch. Keep each feature, fix, or other discrete task isolated from the default branch and unrelated work.
- Make and inspect changes. Edit files, then use git status and git diff to check what changed and what you intend to include.
- Stage and commit the change. Add the relevant files to the staging area, then save a commit with a clear message.
- Push, review, and merge. Share the branch, open a pull request or merge request, respond to review, pass required checks, and merge when approved.
The staging area is important because it lets developers choose which changes go into a commit. The basic cycle is to stage changes with git add, inspect them with git status and git diff, then record them with git commit. A branch-based review process keeps work isolated until it is ready to merge.
Git trends in 2026: Safer conflict resolution and debugging
Git 2.56.0 was released on September 28, 2026. Its release notes describe several changes related to conflict resolution, debugging, and experimental history editing. Check your installed Git version before using newer options, since they may not be available in older releases.
Safer staging after conflict resolution
Git 2.56 adds git add –resolved, which stages paths that are marked as resolved in the index. It checks those paths for leftover conflict markers and stops if it finds any. This can help prevent unresolved conflict markers from being committed.
git add –resolved
Review the result with git status and git diff –staged before committing.
Resetting after git bisect finds a commit
Git 2.56 adds the –reset-when-found option to git bisect. It can reset the working tree automatically after Git identifies the first bad commit.
git bisect start –reset-when-found
By default, Git returns to the original state. To leave the first bad commit checked out instead, specify found:
git bisect start –reset-when-found=found
This can help automate regression investigations, but make sure the test used by git bisect run reliably reports whether each revision is good or bad.
Experimental history editing
The Git 2.56.0 release notes describe git history drop as an experimental command. It removes a commit and replays its descendants onto the removed commit’s parent. Because this changes history, check the command’s documentation for your installed version and avoid using it on shared history unless your team has agreed on the operation and recovery plan.
Performance work for large repositories
Git 2.56 includes performance improvements to repository operations, including merge-base computation. GitHub reported significant improvements in specific large-repository evaluations, but the results depend on repository size and workload. Benchmark your own repositories before assuming the same speedup.
For engineering leaders, the practical approach is to track Git updates, test new commands in a safe environment, and update internal documentation only after verifying that developers and CI runners support the relevant version.
Five Git Practices That Keep Teams Aligned
Reliable version control depends on shared conventions, safe recovery, and review discipline, not just individual command knowledge.
Set Branch and Commit Conventions
Define branch naming rules, commit-message expectations, and a consistent process for integrating changes into the main branch. Shared conventions make work easier to review and maintain.
Agree on Rules for Shared History
Clarify when to rebase and when to merge. Explain why rewriting commits that other developers depend on can disrupt collaboration and complicate recovery.
Build Review Into the Workflow
Use pull requests, automated checks, and explicit approval requirements. A pushed branch is not necessarily ready to merge; review should verify correctness, maintainability, and compliance with team standards.
Teach Recovery Before an Incident
Train developers to inspect the reflog, identify recoverable commits, and create recovery branches. Practicing these steps before work is lost makes incident response less stressful and more predictable.
Measure Workflow Friction, Not Command Usage
Track regression investigation time, release delays caused by merge conflicts, and developer feedback on workflow interruptions. Use these measures to identify bottlenecks and assess whether process changes are helping.
Make Git Work for the Engineering Team
Git productivity is less about memorizing a long list of commands and more about knowing what to do when development is interrupted, a change needs review, or a bug proves difficult to trace. Start with everyday commands and establish consistent team conventions. Introduce tools such as git bisect, git reflog, and git worktree to address recurring problems. Over time, measure whether these practices reduce avoidable delays and make the engineering workflow easier to manage.
Frequently asked questions
A typical workflow involves updating your view of the repository, creating or switching to a branch, making and reviewing changes, staging and committing those changes, and pushing the branch for review before merging.
Commands such as git status, git diff, git stash, git switch, and git log support everyday development. git bisect, git reflog, and git worktree are especially useful for debugging, recovery, and parallel work.
Rebase replays commits on a new base and can keep a feature branch’s history linear. Merge combines branch histories and records the integration point. The right approach depends on the team’s workflow and whether the commits are already shared.
Run git reflog to inspect recent reference movements. If you find the commit, create a new branch at its hash so you can inspect and preserve it. Avoid running further destructive commands until you have located the work you need.
A useful set of 12 is git init, git clone, git status, git diff, git add, git commit, git log, git branch, git switch, git fetch, git pull, and git push. Developers should also learn commands for reviewing, reverting, and recovering changes as their work requires.
Open a terminal in your project directory and enter a Git command followed by any required options or paths.
For example, run git status to inspect the repository, git add <file> to stage a change, and git commit -m “Describe the change” to record it. Use git help <command> or git <command> –help to read documentation for a command.
