git clone in Practice: Shallow and Submodules

git clone downloads a repository and its entire history — and its flags decide how much of that you actually need. Full clone for development, shallow for CI, single-branch for one focus: choosing deliberately saves minutes on every machine you set up.

The basic clone #

$ git clone https://github.com/aospix/aospix-terminal.git
$ git clone https://github.com/aospix/aospix-terminal.git my-terminal
$ cd aospix-terminal && git log --oneline | head -3

The clone brings every branch as remote-tracking refs (origin/main and friends), checks out the default branch, and wires origin as the remote — push and pull work immediately.

Shallow: when history does not matter #

CI systems, Docker builds, and throwaway review checkouts rarely need ten years of history. --depth takes only the newest N commits:

$ git clone --depth 1 https://github.com/aospix/aospix-terminal.git
$ cd aospix-terminal && git log --oneline | wc -l
1

The trade-offs are real: some operations (rebase across the cut, bisect) need history you did not fetch, and git fetch --unshallow repairs that when a shallow clone outgrows its purpose.

The local shortcut #

Cloning a directory on the same machine uses hard links — instant, and the default origin is that path, which is exactly right for experimenting with someone's local work or seeding a new machine from an old disk.

After the clone #

Two habits on every fresh clone: confirm the remote and fetch tags —

$ git remote -v
origin  https://github.com/aospix/aospix-terminal.git (fetch)
$ git fetch --tags

Tags carry release markers (tagging); forgetting to fetch them on a shallow clone is why CI sometimes cannot resolve a version.

Remotes in depth are git remote; reading what you cloned starts with status and log. The Git series continues.