Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Git Remotes  ›  Lesson

Pushing and Pulling

Pushing / Pulling Changes 12 mingit push uploads local commits to a remote branch, git pull fetches and merges remote commits, and a push is rejected when the remote has commits you do not have.

Pushing and Pulling

Asha committed a new soup recipe on her laptop. Ravi committed his dal recipe on his. Neither can see the other's work yet, because commits live in each person's own repository until they are sent or received. Push sends; pull receives.

The rule

Push sends your commits up; pull brings theirs down and merges them in.

Pushing uploads commits from a local branch to the matching branch on a remote:

git push -u origin main    # first time: push and remember origin/main as upstream
git push                   # afterwards: the upstream is remembered

-u (short for --set-upstream) links your local main to origin/main, so later a plain git push or git pull knows where to go. A new branch needs its own first push: git push -u origin vegan-pancakes.

Push sends commits only. Uncommitted edits and unstaged files stay on your machine.

Pulling downloads new commits from the remote and merges them into your current branch:

git pull

Under the hood, git pull is two steps: git fetch (download) followed by git merge (combine). So everything from the merging lesson applies: it can fast-forward, create a merge commit, or stop with a conflict for you to resolve. Some teams configure pull to rebase instead of merge, a choice that belongs to more advanced Git work. Recent versions of Git ask you to make this choice once, and refuse to pull diverged branches until you do. To get the merging behaviour this course uses, run:

git config --global pull.rebase false

Rejected pushes. If the remote branch has commits you do not have, Git refuses your push:

! [rejected]        main -> main (fetch first)
error: failed to push some refs

This is Git protecting other people's work. Pushing would throw their commits away. The fix is to pull first, combine the histories, then push.

The shortcut

Before pushing, think "pull, then push." Your commits can only go up cleanly if the remote has nothing you are missing.

Soup and dal meetStep 1 of 4

  1. Ravi goes first

    Ravi commits dal.md and runs git push. The remote main now has his commit.

The trap is "forcing" a rejected push to make the error go away. A force push replaces the remote's history with yours and silently deletes your teammates' commits. Pull, combine, then push.

Drills

Answer fast — trust the rule.

quick drill

What does git pull do?

quick drill

What does -u in git push -u origin main do?

quick drill

Asha's push is rejected because the remote has commits she does not have. What should she do?

quick drill

Asha edited chai.md but did not commit, then ran git push. Is the chai edit on the remote?

Remember

  • Push sends your commits up; pull brings theirs down and merges them in.
  • Pull, then push; a rejected push means the remote has work you lack.
  • Never force a rejected push on a shared branch.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainThe rejected push

Asha's git push is rejected with "fetch first". Explain why Git refused, what she should do step by step, and why force pushing is the wrong fix on a shared branch.