A beginner’s guide

What actually travels in a `git push`?

Git does not zip up the folder on your laptop. Open one tiny push and the pieces become visible: saved file contents, a folder listing, a commit, and a request to move a branch label.

August 2026 · 9 min · 4 diagrams

01 · Start with one edit

THE EXAMPLEOne file changes. The project does not start over.

Imagine a tiny project with three entries: hello.txt, README.md, and a src/ folder. You change only one line: hello becomes hello, Git.

The folder on your computer is still where you edit. git add hello.txt puts the version you chose into a selected list for the next save. Git calls that selected list the index.

Illustrative example

hello.txt: hello → hello, Git
README.md: unchanged · src/: unchanged

Keep three places apart: the files you are editing, the selected list for the next save, and the saved version created by git commit. A push comes later.

Act 02Names and contentsIllustrative example

Git calls this saved folder listing a tree

Root folder listing

A map of the names in this project folder

hello.txt→ new contents

README.md→ unchanged contents

src/→ unchanged subfolder

Saved records the listing points to

New contents of hello.txthello, Git

README contentsunchanged record already used before

src/ folder listingunchanged subfolder record already used before

Step 1 / 4

Git keeps the words and the filename separately.

The new words hello, Git are saved as one record. Git calls a saved file’s contents a blob. A blob contains the contents, but it does not contain the name hello.txt.

Step 2 / 4

So something else must say where those words belong. Git saves a folder listing: a map with rows for hello.txt, README.md, and src/.

Step 3 / 4

The hello.txt row points to the new saved contents. The unchanged rows can keep pointing to the records the old version already used.

Step 4 / 4

Git calls this saved folder listing a tree. A tree maps names to saved file contents, or to another tree when the name is a subfolder.

What to watch Read the left card as a folder map: names on the left, saved contents or subfolders on the right. The simplified table is illustrative; the relationship is how Git represents folders.

Step 1 / 4

A commit saves one complete project version.

The root folder listing now describes this project version: new hello.txt, unchanged README.md, and unchanged src/.

Step 2 / 4

A commit points to that root folder listing. It does not carry a physical folder inside it; it points to the map that describes the folder.

Step 3 / 4

The commit also points to the earlier commit. That one link is how this project version becomes part of a history of versions.

Step 4 / 4

main is a readable label, called a ref, that now points to the new commit. The label moves. Both saved versions remain.

What to watch The commit points to the folder map and the version before it. The blue main bookmark points to the commit; it does not carry project files.

Act 04The pieces that travel3 in this example

Your Git history

Has old version and the three new records.

earlier saved version

unchanged README contents

unchanged src/ folder listing

new contents of hello.txt

new root folder listing

new commit

Remote Git history

Already has old version and unchanged records.

earlier saved version

unchanged README contents

unchanged src/ folder listing

new contents of hello.txt

new root folder listing

new commit

request accepted: main → new commit

Illustrative: 3 records

Git packfile · a compact parcel

new contents of hello.txt
new root folder listing
new commit

Step 1 / 4

This is what the example push sends.

The remote already has the earlier version plus the unchanged README and src/ records. In this example, Git does not need to send those again.

Step 2 / 4

Git gathers records for transfer in a compact bundle called a packfile. Think of it as a parcel with a contents list, not a literal cardboard box.

Step 3 / 4

Here the parcel contains three new pieces: the changed file contents, the new root folder listing that names those contents, and the new commit that saves the listing.

Step 4 / 4

After receiving those records, the remote can accept the request to move main to the new commit. The host’s rules decide whether it accepts that request.

What to watch The parcel names every piece it carries. Three is correct only for this stated example: one root-level file changed and the remote already had everything else.

05 · Why this is not “only diffs”

ONE USEFUL CORRECTIONGit saves a version map, then can compare maps later.

The commit above points to a complete root folder listing. That listing reaches every file in the project, including unchanged ones. Git can reuse the saved records that did not change, so a new version is not a fresh copy of every file.

When you ask for git diff, Git compares two saved versions and shows the difference. The difference is useful output; it is not the only way Git understands the project.

Act 05The service around GitResponsibility map, not server map

Git history

saved file contentsfolder listingscommitsbranch labels

What a host can keep in a bare repository: repository data, without a checked-out project folder.

Team work

access rulespull requestreview notespull request → discusses commits

Features that help people decide what to share, review, and merge.

Optional large files

pointer in Gitlarge file through LFS

Git LFS can keep a pointer in Git while selected large payloads live in its separate storage system.

This diagram classifies responsibilities. Historical public writing describes ordinary Git repositories replicated at the application layer; it makes no claim about GitHub’s current server count, location, or write process.

Step 1 / 4

GitHub adds a service around Git history.

A host can keep Git’s saved contents, folder listings, commits, and branch labels in a bare repository: repository data without a checked-out project folder.

Step 2 / 4

The host also adds access rules and team tools: pull requests, issues, and reviews. Those features help people work with Git history; they are not replacements for it.

Step 3 / 4

A pull request points people at commits to discuss. The discussion and review notes are not themselves a blob, folder listing, or commit.

Step 4 / 4

Git LFS is optional. For a selected large file, Git stores a pointer while LFS stores and retrieves the file’s payload.

What to watch Git history, team tools, and optional LFS have separate jobs. The shelves are not a physical diagram of GitHub’s infrastructure.

06 · A compact glossary

KEEP THE JOBS APARTThree terms that become simpler once the pieces are visible.

Blob: Saved file contents. It holds the words hello, Git, but not the name hello.txt.
Tree: Git’s saved folder listing. It maps hello.txt to those contents and maps the other folder names too.
Commit: A saved project version. It points to the root tree and to the previous commit.
Branch: A readable label such as main that points to a commit.

Thing	Its job	What it is not
Git push	Transfers records the remote needs, then proposes branch updates.	A zip upload of your current working folder.
Git history	Keeps file contents, folder listings, and commits connected.	A pull-request conversation or permission rule.
Pull request	Gives a team a place to discuss commits and decide what to merge.	A commit or a separate copy of all project files.

07 · The answer

A push sends the pieces that describe the new version.

In this example, the remote already has the old version. So Git sends three new records: the new words in hello.txt, the new folder listing that names those words, and the commit that saves that listing. Then it asks to move main to that commit.

GitHub can host this same history and add pull requests, reviews, and access rules around it. Once you can picture the contents, folder listing, commit, and branch label as separate pieces, a git push stops looking like a mysterious folder upload.