3.5 Remote Repositories, fetch, pull, and push

Prerequisites: Resolving Merge Conflicts

Estimated time: 15 minutes

Practice environment: Conceptual examples are offline; a local bare repository is used at the end to simulate a remote

You are ready to continue when: you can explain the difference between local branches, local remote tracking references, and server branches

All timelines so far have been confined to a single disk. To involve another working copy, you must first distinguish three key elements: local branches, local remote-tracking references, and branches on the server. A remote repository is essentially another Git repository; platforms like GitHub and GitLab add account management, permissions, code reviews, and continuous integration on top of that.

Add a Remote and First Push

Until the offline simulation section, the snippets illustrate commands that require a real repository URL and suitable permissions. Do not execute these placeholders in the ongoing practice repository; the final section adds its local remote directly.

git remote add origin https://example.invalid/team/project.git
git remote -v
git push -u origin main

origin is a conventional alias, not a keyword; -u sets the upstream for the current branch. The example domain is intentionally unreachable. Real pushes may be rejected due to authentication, permissions, branch protection, checks, or server-side hooks, errors must be read in full to understand the cause.

Common cloning:

REPOSITORY_URL=https://example.invalid/team/project.git
git clone "$REPOSITORY_URL"

This typically creates origin, remote tracking references, and checks out the remote default branch. origin/main is a local record and does not automatically synchronize with the server in real time; it is updated only after a fetch, pull, or push operation.

Fetch First, Then Decide How to Integrate

git fetch origin
git log --oneline --left-right main...origin/main
git diff main...origin/main
git merge --ff-only origin/main

fetch downloads objects and updates remote references without modifying the current working directory. --ff-only advances a branch when a fast-forward is possible and refuses a diverged history. Inspect the divergence before choosing how to integrate it.

git pull is equivalent to fetch followed by the configured integration action. The second part may be a merge, a rebase, or simply fast-forwarding, never a guaranteed "fetch + merge":

git pull --ff-only
# Or, when the team agrees to replay local commits: git pull --rebase

Push is Rejected

A non-fast-forward push is just one of many possible causes. Follow this troubleshooting sequence:

1. Read the full error message returned by the remote and review the repository rules.
2. git fetch origin Update the local view.
3. Compare changes between both sides using the commit graph and diff.
4. Apply merge or rebase according to team policy.
5. Test the changes and push again.

Do not simply assume --force when a push is rejected. If you must rewrite your personal remote branch, first confirm that no one else depends on it, then use --force-with-lease; the lease checks whether the remote reference still matches its expected value. The form without an explicit value relies on local remote-tracking references, which an IDE may update through background fetches. For a strict check, specify the expected commit you reviewed. See the git-push lease documentation. Shared main lines should typically be protected by the platform to prevent force pushes.

Offline Simulation of Remote Collaboration

cd "$workdir"
git init --bare -b main remote.git
git -C project remote add origin "$workdir/remote.git"
git -C project push -u origin main
git clone "$workdir/remote.git" colleague

A bare repository lacks a standard working directory, making it well-suited for local server-side experimentation. The next page covers review and merge policies; the following lab demonstrates collaboration between two clones.

→ Next: Rebasing, Pull Requests, and Workflows