Image of Git Cheat Sheet: 14 Essential Git Commands for Experts

ADVERTISEMENT

Table of Contents

Introduction

In previous posts, we’ve discussed some essential Git commands for beginners and intermediate users.

In this article, we’ll discuss 14 essential Git commands for experts.

1) Git Submodule

With Git submodules, users can keep and maintain a Git repository within a subdirectory of another Git repository. A Git submodule is a reference that points to a specific commit in an external repository. By default, running the git submodule command displays the status of any existing submodules within the current repository.

Users can add a new submodule repository using the command:

git submodule add <remote-git-submodule-repo-url>

A submodule acts just like an ordinary Git repository, but it is nested inside an existing Git repository. Each submodule has its own .git/ hidden directory containing the object database and Git configuration for the submodule. You can work with files as normal in the submodule, making changes, adding them to the staging index, committing them, and pushing your changes to the remote branch.

However, you will need to commit any updates to the submodule (whether the committed code was changed locally or pulled from a remote) in the parent repository. This allows submodules to be treated almost like dependencies for your parent project. There are an assortment of other submodule commands you can learn about by running the command git help submodule.

2) Git Show

The git show command displays metadata about Git objects in the current repository. When run without any arguments, this command displays information about the HEAD commit, including the commit author, date, message, changed files, and changes lines.

For example, to view the log message and text differences for a specific commit ID, the user can run:

git show <commit-id>

Instead of specifying a commit ID, you can use a branch name, tag name, Git blob hash, or tree hash. In each case, git show will display the content of that object.

3) Git Clean

The git clean command removes untracked files from the working tree. If no path is provided, untracked files are removed recursively starting from the current directory. By default, untracked directories are ignored, but untracked directories can be explored recursively with the addition of the -d flag. If a path is provided, git clean only affects files matching that path.

Since this command permanently deletes files, it's good practice to first run this command with the --dry-run option. With this option, users can see which files will be removed by the command.

git clean --dry-run

After confirming the list of the files to be removed, the git clean command can be executed without the --dry-run option.

4) Git Fsck

The git fsck command checks the connectivity and validity of objects in the git repository. Using this command, users can confirm the integrity of the files in their repository and identify any corrupted objects. This command will also inform the user if there are any dangling objects in the repository. These objects may be taking up unnecessary space in the repository and can be removed by running git gc.

git fsck

Here is some sample output from the git fsck command:

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3475/3475), done.
dangling blob 2f42ad266a192bd843cd65b2c1cd913e0c97b5d2
dangling blob 31c80610b88c73e8862461db80fb4af3ace39a16
dangling blob b448bc1853b62fe673e0212bb703b2ebe5c45705
dangling commit 9ad0b2fbc1def3fcf1fa98e29460e28e67c95239
dangling blob 19d17737b2de1d1d196d0121a04d8bb0876c472e
dangling blob e2920e4c6c2c8e18334668a443cb89affd59feb7
dangling blob ea188a38f03b5843f9c78687a887110a9e972db5
dangling commit 6324ab475307efbfa79e628a500d747a4bb3a91f

5) Git Gc

The git gc command triggers Git's garbage collection utility within the current repository. This command deletes all inaccessible (orphaned) commits and compresses stored Git objects, freeing up memory space. Git garbage collection is automatically run during commands like git pull, merge, rebase, and commit, but it can be helpful to run the command manually to clean up repositories that are updating frequently.

git gc

Here is some sample output from the git gc command:

Enumerating objects: 6538, done.
Counting objects: 100% (6538/6538), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4045/4045), done.
Writing objects: 100% (6538/6538), done.
Total 6538 (delta 3329), reused 3413 (delta 1763)
Computing commit graph generation numbers: 100% (546/546), done.

Note that running git fsck now after running git gc, we don't see the dangling objects listed anymore:

git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (6538/6538), done.

6) Git Reflog

The git reflog command is used to view the past tips of a local branch. By default, git reflog shows the past info for the HEAD ref. To view the reflog of a specific ref, users can identify a ref by name:

git reflog show ref-name

Alternatively, to view the reflog for all refs, users can execute the command:

git reflog show --all

7) Git Cat-file

The git cat-file command displays the content or type for a specified object in the repository. Users must provide a name of the object which can be either a blob, tree, commit, or tag. To indicate what content should be displayed, users can add one of three flags: the -t flag to show the object type, the -s flag to show the object size, or the -p flag to show the object's content.

For example, the -p can be used to displayed a commit's tree, parent, author, committer, and commit message:

git cat-file <commit-id> -p

8) git write-tree

The git write-tree command creates a new tree in the object database based on the staging staging index. To create a tree based on a subdirectory, users can add the --prefix flag and specify the name of the subdirectory. After running this command, the hash of the new tree is printed to standard output.

For example, to write a tree based on a subdirectory in the current repository, users can execute the command:

git write-tree --prefix=subdirectoryPath

9) Git Read-tree

The git read-tree command copies the state of an existing Git tree object into the index. By default, this command does not update the existing files. This command can also be used to merge one or more trees into the index by adding the -m flag. For example, to merge an existing tree into the index, developers can use the command:

git read-tree -m <tree-hash>

10) Git Commit-tree

The git commit-tree command creates a new commit object based on a provided tree. Unlike a regular commit, this commit does not set a new HEAD state. Instead, it just creates a commit object based on the state of the existing tree and saves it in the object database, named using the hash of its content. After running this command, the commit ID is printed to standard output. This command can be useful when users want to create a commit in the object database without updating the history of the working branch.

git commit-tree

11) Git Show-ref

The git show-ref command lists all refs available in the local repository along with their associated commit ID's. By default, this command displays all tags, heads, and remote refs. To display only tags, users can add the --tags flag and to display only heads, they can add the --head flag. This command can also be used to check for any existing objects that match a specific pattern.

For example, to check for any ref matching the name master, developers can use the command:

git show-ref master

To only get objects matching an exact path, users can add the --verify flag. To locate a branch at refs/heads/master, for example, developers can use the command:

git show-ref --verify refs/heads/master

12) git update-ref

The git update-ref command is used to make a ref point to a new Git object. For example, to update the current branch head to point to a new object, developers can use the command:

git update-ref HEAD <new-ref>

If the user wants to check whether the new object is equivalent to the old object before updating the current ref, they can add the old object has a third argument. Then, the ref will only be updated if the values of the objects match. For example, to update the current branch head to point to new object if that object matches the current object, developers can use the command:

git update-ref HEAD <new-ref> <current-ref>

13) git rev-list

The git rev-list command lists the objects from one or more refs in reverse chronological order. To get objects from a specific ref, the user can include that ref as an argument:

git rev-list <ref>

This command also supports various flags to request certain objects. For example, users can add the --all flag to get the objects from all refs, the --branches flag to get objects from all branch heads, and the --tags flag to get objects from all tags.

14) git verify-pack

The git verify-pack command is used to confirm the validity of a Git packfile. This command requires the user to supply a path to the .idx file that is associated with the Git packfile in question. This .idx file is used to quickly locate objects within the associated packfile. Git packfiles are an effective way to organize large sets of files within a Git repository. To get the list of all objects in the pack, the user can add the -v (verbose) flag:

git verify-pack packfile.idx -v

Conclusion

With these advanced commands, developers can perform administrative tasks to efficiently work with and maintain their Git repositories. For repositories with frequent contributions from multiple users, these commands can be essential for maintaining a clean project.

If you want to learn about Git in more depth, check out our top Git books.

If you're interested in learning more about how Git works under the hood, check out our Baby Git Guidebook for Developers, which dives into Git's code in an accessible way. We wrote it for curious developers to learn how Git works at the code level. To do this we documented the first version of Git's code and discuss it in detail.

We hope you enjoyed this post! Feel free to shoot me an email at jacob@initialcommit.io with any questions or comments.

Final Notes