10 New Git Commands You Should Know

If you've worked with Git long enough, you may have encountered some common pain points: operations slowing down as your repository grows, accidentally overwriting changes when switching branches, or struggling with massive monorepos.

Fortunately, like any other tool, Git continuously evolves and adds new features to make our lives easier. While some of these commands aren't brand new, they are still hidden gems with significant potential to improve your workflow. If you're already familiar with some core tips and tricks (like those mentioned in "15 Git command-line tips every developer should know"), this article will introduce you to ten additional commands that can take your Git skills to the next level.

1. git switch - A Safer Way to Switch Branches

Before Git 2.23, git checkout was the primary command for switching branches, but it did much more than that. You could use it to restore files, create branches, or check out specific commits. This made it powerful but potentially confusing, especially when you just wanted to switch branches without touching your files.

That's why Git 2.23 introduced git switch as a more focused alternative for branch operations. With git switch, you can concentrate solely on branch management:

Bash

# Switch to another branch
git switch feature-branch

# Create and switch to a new branch
git switch -c new-branch

This clarity reduces the risk of accidentally overwriting files or making unintended changes. If you've ever hesitated to use git checkout for fear of doing something wrong, git switch will simplify the process.

2. git restore - Safely Undo Changes

Undoing changes typically involved using git checkout to revert files or git reset to move the HEAD of a branch. However, both commands have the potential to alter your branch state if used incorrectly: git reset can move your branch HEAD, while git checkout can switch branches or check out a different commit, disrupting the current branch.

Git 2.23 introduced git restore to focus exclusively on undoing changes to files. It provides a safer and more direct way to revert changes in the working directory or staging area, clearly separating file operations from branch management tasks:

Bash

# Discard working directory changes
git restore main.js

# Unstage changes from the index
git restore --staged main.js

This is especially useful for beginners or in critical situations where precision is key. You can undo changes without worrying about accidentally switching branches or resetting commits.

3. git maintenance - Automate Repository Health

As a repository grows, performance can degrade. Operations like git fetch, git status, or git log can slow down and unused data can clutter your repository. Before Git 2.29, you had to manually run commands like git gc (garbage collection) or git repack to keep your repository optimized.

Git 2.29 introduced git maintenance, which automates these tasks for you:

Bash

# Enable automatic maintenance
git maintenance start

# Run cleanup tasks immediately
git maintenance run

What's happening behind the scenes?

• Garbage Collection: Removes unreachable objects, such as commits discarded during rebase or branch deletion.
• Repacking: Merges fragmented pack files to improve storage efficiency.
• Commit Graph Updates: Optimizes commit history traversal, speeding up commands like git log and git blame.

Using git maintenance keeps your repository healthy without manual effort.

4. git sparse-checkout - Efficiently Handle Large Repositories

Monorepos are great for managing multiple projects, but cloning the entire repository when you only need a specific directory can be inefficient. Git 2.25 introduced git sparse-checkout to solve this problem.

Bash

# Enable sparse-checkout mode
git sparse-checkout init

# Only fetch specific directories
# You can specify multiple directories separated by spaces
git sparse-checkout set services/ docs/

With git sparse-checkout, you can include only the directories or files you need in your working directory, skipping the rest. This is useful for large teams working on separate portions of a monorepo and will save you time and disk space.

5. git log --remerge-diff: Better Understand Merges

Merge commits often show which branches were merged, but they don't always explain the specific changes introduced, especially when conflicts were resolved during the merge.

Starting with Git 2.35, you can use:

Bash

git log --remerge-diff

This option recreates the merge commit by replaying the recorded merge strategy and shows the exact changes it introduced. It's useful for debugging merge conflicts or reviewing complex merge history.

6. git blame --ignore-rev - Skip "Noisy" Commits

When your team makes bulk formatting changes, git blame can lose its usefulness, as every line ends up pointing to the formatting commit instead of the original author.

Introduced in Git 2.23, the --ignore-rev option lets you exclude such commits:

Bash

git blame --ignore-rev commit-hash

To maintain this exclusion, you can set up an ignore-revs file:

Bash

# Add commit hash to the ignore-revs file
echo commit-hash >> .git-blame-ignore-revs

# Tell Git to use the file
git config blame.ignoreRevsFile .git-blame-ignore-revs

This helps you focus on meaningful authors and can be useful in codebases with frequent style updates.

7. git range-diff - Compare and Track Changes Between Commit Ranges

Rewriting history, whether through rebase, cherry-picking, or interactive editing, can be difficult. After a rebase, you might wonder how the rewritten commits differ from the originals. git range-diff helps by comparing two commit ranges, showing how one range evolved into another and highlighting changes to each commit:

Bash

git range-diff

This command can be used to understand the evolution of a feature or bug fix across different branches.

8. git worktree - Work on Multiple Branches Simultaneously

Switching branches in a single working directory can disrupt your workflow, especially when you need to work on multiple branches. With git worktree, you can create additional working directories linked to the same repository.

# Add a new worktree for a specific branch
git worktree add ../feature-branch feature-branch

# Remove a worktree when you're done
git worktree remove ../feature-branch

git worktree allows you to work on different branches without switching or stashing. You can also create disposable worktrees with a detached HEAD for experimentation or to isolate builds and deployments in separate working directories.

9. git rebase --update-refs - Keep References in Sync

When rebasing (rewriting history), old branches and tags can become broken because the history has changed. Git 2.38 adds the --update-refs option to automatically update these branches and tags to match the new history.

git rebase --update-refs

This command helps Git automatically update branches and tags related to the rebased commits, ensuring history remains consistent.

You can configure Git to automatically update specific branches and tags by setting:

Bash

git config rebase.updateRefs true

This is very useful when working in teams or managing multiple related branches/tags.

10. git commit --fixup and git rebase --autosquash - Fix Commits

Although it has been around for a long time (Git 1.7.4), git commit --fixup is often overlooked, yet it is very useful for keeping commit history clean.

While working, you may discover a need to fix or improve a previous commit. Manually changing commit history is error-prone.

Git provides git commit --fixup and git rebase --autosquash to automate this process:

Bash

# Create a fixup commit for a specific commit
git commit --fixup=<commit-hash>

# Then, during an interactive rebase, automatically squash fix commits
git rebase -i --autosquash <base-branch> 

The --fixup command creates a special commit that will be automatically squashed into the target commit during an interactive rebase. This makes it easier to clean up commit history before merging and ensures related changes are grouped together without manual manipulation.

Conclusion