Introduction

A common Git workflow is to copy someone else's repository, make your own changes, and publish that work under your GitHub account. The exact steps depend on whether you want a simple copy, a fork that stays linked to the original, or a mirror that preserves every branch and tag.

Decide Between Clone, Fork, and Mirror

If you only need the code locally, git clone is enough. If you want GitHub to understand the relationship between your copy and the original project, a GitHub fork is usually the better choice. If you need all refs, including tags and unusual remote refs, use a mirror.

For most personal work, you can clone the original repo and then point origin at a repo you own:

git clone https://github.com/original-owner/project.git
cd project
git remote -v

That gives you a local checkout with origin still pointing at the source repository.

Push the Local Copy to Your Own GitHub Repository

Create an empty repository on your GitHub account first. Do not initialize it with a README if you want the existing local history to push cleanly.

Then either rename the original remote to upstream, or replace it completely.

A clean setup is:

git remote rename origin upstream
git remote add origin https://github.com/your-user/project.git
git remote -v

Now origin is your repository and upstream is the original one.

Push your current branch:

git push -u origin main

If the default branch is master, push that instead:

git push -u origin master

You can discover the current branch with:

git branch --show-current

Keep Pulling From the Original Repository

Once upstream is configured, you can fetch changes from the original project and decide whether to merge or rebase them into your branch.

git fetch upstream
git branch -a
git merge upstream/main

Or, if you prefer a linear history:

git fetch upstream
git rebase upstream/main

Use merge when you want to preserve branch history as it happened. Use rebase when you want your branch to look like it was built on top of the latest upstream tip.

When a GitHub Fork Is Better

If you intend to contribute back with pull requests, the GitHub fork workflow is more convenient than manually cloning and rewiring remotes. GitHub creates your server-side copy and keeps the parent-child relationship visible.

After forking in the UI, the usual setup is still helpful locally:

1git clone https://github.com/your-user/project.git
2cd project
3git remote add upstream https://github.com/original-owner/project.git
4git fetch upstream

That gives you a local clone of your fork, while still making it easy to sync with the original.

Copy Every Branch and Tag With a Mirror

Some migrations require more than the default branch. In that case use a mirror clone.

1git clone --mirror https://github.com/original-owner/project.git
2cd project.git
3git remote set-url origin https://github.com/your-user/project.git
4git push --mirror

This copies all refs, not just the checked-out branch. It is useful for backups or repository transfers, but it is heavier than a normal clone.

Authentication Details That Matter

GitHub no longer allows standard account passwords for Git operations over HTTPS. Use either:

• an SSH remote, such as [email protected]:your-user/project.git
• or HTTPS with a personal access token when prompted

Check your configured remotes if pushes fail:

git remote -v
git config --get remote.origin.url

If you use SSH, test it directly:

ssh -T [email protected]

A Minimal End-to-End Example

This is the shortest safe sequence for the common case:

1git clone https://github.com/original-owner/project.git
2cd project
3git remote rename origin upstream
4git remote add origin [email protected]:your-user/project.git
5git push -u origin main

After that:

git fetch upstream
git merge upstream/main
git push

That pattern keeps the source available without mixing up where your work gets pushed.

Common Pitfalls

Pushing back to the original repository by accident. Rename the source remote to upstream early so origin always means your repo.

Creating the new GitHub repository with starter files. That can cause an unnecessary unrelated-history conflict on first push.

Forgetting which branch name the repo uses. Check with git branch --show-current before pushing.

Using an account password over HTTPS. GitHub expects SSH or a personal access token.

Using git clone when you actually need a full mirror. A normal clone will not preserve every ref automatically.

Summary

• Clone when you need a local copy, fork when you want GitHub linkage, and mirror when you need all refs.
• Rename the source remote to upstream and set your own repo as origin.
• Push your active branch with git push -u origin ....
• Fetch from upstream to keep your copy current.
• Use SSH or a personal access token for authentication.