Sharing with Remote Repositories
INPUT · Slides
01 / 11
Everything you practiced in the previous chapters took place entirely inside your local environment (device). Committing, branching, and merging all happened within your local repository.
In real development, however, developers work together in teams. Remote backups are also essential in case hardware fails or is lost.
This is where shared remote repositories come in.
02 / 11
The most important concept to understand is that a remote repository has the exact same structure (commit history and branches) as your local repository.
The only difference is where it is hosted — typically on cloud hosting services like GitHub or GitLab, or on internal team servers accessible by all collaborators.
Understanding that "a remote is simply another Git repository" makes synchronization intuitive.
03 / 11
Look at the diagram below. The Git workflow encompasses four distinct areas:
While git add and git commit move changes through 1→2→3 locally, git push and git pull synchronize commits between local (3) and remote (4).
04 / 11
Learning remote synchronization requires experiencing changes made by other developers. Without collaborators, push conflicts and remote updates cannot happen.
In this course, exercises allow you to switch to Developer B's workspace using the selector at the top of the screen.
Switching workspaces swaps your working tree, staging area, and local repository to Developer B's machine. The central remote repository (origin) is shared: both developers push to and pull from it.
Exercise evaluation always inspects your environment (Developer A). After making changes as Developer B, always return to Developer A to complete the required synchronization steps.
05 / 11
git push uploads new commits from your local repository to the remote repository.
What gets transferred is the commits themselves. Once pushed, commits with matching hash identifiers appear in the remote repository graph as well.
Crucially, uncommitted changes cannot be pushed. Files must be staged with git add and committed with git commit to your local repository before they can be pushed.
$ git pushTo origin main -> main06 / 11
In your local commit graph, notice the origin/main label.
This is a remote-tracking branch — a local reference pointer recording where the remote's main branch pointed the last time you communicated with origin.
It is not the remote server itself, but a local bookmark representing the known remote state. Understanding this makes the distinction between fetch and pull clear.
07 / 11
git fetch downloads new commits from the remote repository to your local machine without modifying your active branches.
Your local branch (main) does not move forward at all; only the origin/main remote-tracking branch pointer advances.
This is the safest command when you want to inspect incoming remote changes before deciding whether to merge them into your working code.
$ git fetchFrom origin main -> origin/main08 / 11
git pull is a combined command that executes git fetch followed immediately by git merge.
1. Download new commits from the remote repository (fetch)
2. Merge the remote-tracking branch (origin/main) into your currently active local branch (merge)
Consequently, Fast-forward merges, merge commits, and merge conflicts occur under the exact same rules learned in Chapter 2.
$ git pullFrom origin main -> origin/mainUpdating 3b7e5d1..9f2a1c4Fast-forward09 / 11
In collaborative development, you will frequently encounter rejected pushes.
When the remote repository contains commits that your local repository has not yet incorporated, Git prevents you from pushing.
Allowing the push would overwrite and erase the commits created by teammates. Git blocks the push to protect everyone's work.
$ git push! [rejected] main -> main (fetch first)error: failed to push some refs to 'origin'10 / 11
The standard resolution workflow is straightforward:
1. Run git pull to fetch and merge incoming remote commits into your local branch
2. (If a conflict occurs, edit the conflicted files, stage them with git add, and finalize with git commit)
3. Once remote changes are integrated locally, run git push again
"Pull before you push." Remembering this core rule eliminates anxiety when collaborating in Git.
The error notice (fetch first) prompts this exact sequence.
11 / 11
Now try the commands yourself.
The UI displays both your local repository and the remote repository commit graphs. Observe which commits appear and which pointers move as you run commands.
Use git status whenever needed. It provides helpful status messages like Your branch is ahead of 'origin/main' by 1 commit.