Git Clones, Forks & When to Use Them

Once a project is on GitHub, copies of it start to appear. There's the one on GitHub, one on a teammate's laptop, another inside an AI app builder, and sometimes a separate copy under someone else's account. When those copies stop matching, work goes missing in ways that feel mysterious, and nobody is sure which version is current. AI app builders add one more copy to keep track of, and they don't always say when they sync.

Git is designed around copies. A remote repository lives online and acts as the shared version, while a local repository sits on one computer. A clone is a linked local copy that sends changes back with a push and receives new ones with a pull. Cloning copies everything, including the full history. A fork is a copy on GitHub under a different account, the usual way to propose changes to a project you can't edit directly. GitHub keeps track of how far each copy has moved, which is why some pages say a branch is ahead or behind.

Every copy can drift. Knowing where each one lives, and how changes travel between them, is what keeps one person's work from quietly overwriting another's. In practice, that means syncing often and checking which copy you're looking at before you edit.

Local vs. remote repositories

Git projects usually exist in more than one place. A remote repository is a copy hosted elsewhere, most often on GitHub, that a team shares. A local repository is a copy on one person's computer, with its own full history.

Changes made locally stay local until they're sent to the remote. A designer can commit three fixes on a laptop, and teammates won't see any of them until those commits are pushed to GitHub. In the other direction, new work on GitHub doesn't appear on the laptop until it's pulled down.

This is the most common source of confusion for newcomers, and it explains messages like "Your branch is ahead." Two copies of the same project can be different at any moment, and syncing is a deliberate step, not something that happens on its own.

The origin remote

A local repository keeps a list of the remotes it's connected to, each with a short nickname. When a repository is copied from GitHub, Git automatically names that source origin^[1].

So origin isn't a special server or a GitHub feature. It's just the default name for the place a project came from. When tools say they pushed to origin, they mean they sent commits back to that original repository, which is usually the one on GitHub.

Seeing origin/main in a tool or message means the copy of the main branch as it existed on the remote the last time the two were synced. Comparing main with origin/main is how tools work out whether a computer's copy is ahead or behind.

Cloning a repository

Cloning creates a complete local copy of a repository, including every file and its full history, and keeps it linked to the remote it came from. Once cloned, the copy can send its own commits back with a push and receive new ones with a pull.

GitHub's Code menu offers several ways to get a project. Cloning by HTTPS or SSH sets up that linked copy, and Open with GitHub Desktop does the same without commands. Download ZIP is different: it saves the current files only, with no history and no link back to GitHub.

The difference matters later. Changes made to a downloaded ZIP can't be pushed anywhere, so they have to be copied back by hand. For anything beyond a quick look, a clone keeps the work connected.

Pushing and pulling changes

Syncing between a local and a remote repository happens in two directions. Pushing sends local commits up to the remote, so teammates can see them. Pulling brings new commits from the remote down to the local copy, so it catches up with everyone else's work.

A typical round looks like this: pull the latest version, edit files, commit the changes, then push them to GitHub. A related action, fetching, downloads the latest information from the remote without changing any local files, which is handy for checking what's new before pulling.

Tools often hide these steps behind one button labeled Sync, and AI builders may push automatically. Underneath, it's still push and pull, which is why a change sometimes appears on GitHub only after a sync finishes.

Pro Tip! Pull before starting new work. Beginning from the latest version prevents most conflicts before they happen.

Commits ahead and behind

Git compares two copies of a branch by counting commits. A copy is ahead when it holds commits the other doesn't have yet, and behind when the other holds commits it's missing. GitHub shows this on branch pages, and AI builders show it in messages like GitHub is 2 commits ahead.

Each state has a simple fix. Being ahead means there's local work to push. Being behind means there's new work to pull. Being both ahead and behind means the copies have diverged: each side changed since they last matched, and the work has to be combined.

Reading these counts correctly prevents lost work. Pushing while behind is usually refused until the missing commits are pulled, which is Git's way of making sure nobody overwrites changes they haven't seen.

Forking a repository

A fork is a copy of someone else's repository, saved under a different account on GitHub. Forking is the usual way to contribute to a project without permission to change it directly, which describes most open-source projects.

The flow is straightforward. Someone forks the project, makes changes in their own copy, and then opens a pull request asking the original project to accept them. The maintainers review the request and decide whether to merge it. This model is popular in open source because it lets newcomers contribute without being added to the project first ^[2].

Forks also suit experiments. Starting from an existing template or example and taking it in a new direction is a fork too, one that may never send anything back.

Pro Tip! Many projects ask for an issue before a pull request. Reading CONTRIBUTING first can save a fork full of wasted work.

Fork vs. clone

Forks and clones are both copies, but they live in different places and serve different purposes. A fork is a copy on GitHub under another account. A clone is a copy on a computer. A project can even be forked first and then cloned, so the work happens locally and gets pushed to the fork.

The difference becomes clear when proposing a change to someone else's project. Cloning it onto a laptop gives a working copy, but pushing changes back requires permission the newcomer doesn't have. Forking first creates a copy they own on GitHub, from which a pull request can be opened.

A simple way to remember it: a fork is about ownership on GitHub, and a clone is about location on a computer. Contributing to a project without access starts with a fork.

When two copies drift apart

Two copies of a project drift apart when each one changes after they last synced. A designer edits the homepage in an AI builder while a developer fixes the same page on GitHub, and now neither copy has the other's work.

Git can usually combine the two automatically. When both sides changed different lines, the result simply includes both. When both sides changed the same lines, Git can't guess which version is right and reports a conflict, which someone has to resolve by choosing what to keep.

AI builders handle drift in different ways. Some push their version to a separate branch so nothing is lost, while others overwrite one copy with the other. Syncing often, and checking which copy is current before making changes, keeps drift small and conflicts rare.