Fast clone of large git repo to read code in IDE

Gerry Tan — Wed, 27 Aug 2025 07:33:16 +0000

How often do you find yourself wanting to clone a repo owned by someone else just to load it in your IDE for quick searching / improved navigation / syntax highlighting / etc.?

This is problematic on a large repo with tons of history because the initial full clone can take an hour or more!

Fear not! Shallow git clone to the rescue. Next time you're in this situation:

git clone --depth=1 <url_of_the_repo>
Load the code in the IDE

You'll notice the clone will be a lot faster!

A shallow clone works fine if all you do is just reading code in IDE. However other functionalities are limited / won't work.

What you should do right after a shallow clone is open a new terminal window, and run:

git fetch --unshallow

Which will fetch all those long history.

Let this run for however long it wants (and make sure you're not on limited mobile data plan 😉).

The bottom line is, using this method you can temporarily bypass the expensive fetching of full history, and get only the latest version for immediate reading 🍻.

And by the way most CI/CD pipeline does a shallow clone too since all they care is the last version of the code.

Squash git commits before pushing

Gerry Tan — Wed, 09 Jul 2025 08:33:28 +0000

Given the following commits on a feature/something-cool branch:

The git command git rebase -i A will let you squash B, C and D into a new commit E like this:

(Observe how the commit hash B, C and D are gone, replaced with E., This will be important for the next section)

This is especially useful to tidy up local commits with crude messages like fixed typo, whitespaces or unit test failures.

Remember that your colleagues (or anyone on the internet if your project is open source) often refer to git history to get more context of particular implementation.

Popular IDE comes with some sort of git blame feature so reader can understand when / where / why a particular implementation is done a certain way.

Alternatively, you can set your repo to do squash-on-merge strategy

But don't overdo it during active code review

Say your colleague leaves bunch of code review comments on your PR at commit E, and you push more changes to address them, they would want to know "what's changed since E", so avoid doing any rebase that rewrites E.

Bad example: E is replaced by F

DEV Community: Gerry Tan

Fast clone of large git repo to read code in IDE

Squash git commits before pushing

But don't overdo it during active code review