Sending commits up: git push
Your commits are born local. Nobody on GitHub sees them until you push.
$ git push origin main To https://github.com/octocat/recipe-book.git a1b2c3d..c7d8e9f main -> main
Read the command as send my new main commits to origin, and the last line of output as the remote's main moving from a1b2c3d up to c7d8e9f.
The very first push of a new branch adds -u.
$ git push -u origin main
That flag links your local branch to the remote one, so from then on a bare git push or git pull knows where to go without you naming the remote and branch every time.
Push only uploads commits. Uncommitted edits stay home, and so do staged changes that were never committed, since staging is not history. That is one more reason the commit rhythm from lesson 2-3 matters: work you did not commit is work your teammates cannot receive.
Getting commits down: git pull
While you slept, a teammate pushed commits. Your clone does not update itself, so you ask for the news.
$ git pull
Updating c7d8e9f..f0e9d8c
Fast-forward
cake.txt | 2 +-git pull downloads the remote's new commits and merges them into your current branch, often as a fast-forward from lesson 5-3 when you had no commits of your own.
Then there is the rite of passage every beginner hits, a rejected push.
$ git push origin main
! [rejected] main -> main (fetch first)
error: failed to push some refsTranslated, the remote has commits you do not have, and Git will not let you push past them blindly, because doing so would drop your teammate's work from the branch.
The fix is the polite order: pull first, which merges their work into yours and may hand you a unit-6 conflict, and then push. Pulling before you start working and again before you push makes rejections rare, since the window for someone to get ahead of you shrinks to minutes.
A recorded session
This session walks the rejected-push rite of passage. A commit was made locally, but a teammate pushed to origin in the meantime.
Each step below shows the command and the output it printed.
Step 1. Try to push your main branch to origin.
~/recipe-book $ git push origin main ! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/octocat/recipe-book.git'
The parenthetical fetch first is the instruction, not just a diagnosis.
Step 2. Bring their commits down and merge them into yours.
~/recipe-book $ git pull Merge made by the 'ort' strategy. cake.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A true merge this time, since both sides had new commits, so a merge commit was created.
Step 3. Push again.
~/recipe-book $ git push origin main To https://github.com/octocat/recipe-book.git c7d8e9f..3f2e1d0 main -> main
Accepted now, because your main contains their commit as well as yours, so nothing on the server would be left behind.
After a push rejected with fetch first, the correct next move is to git pull, then push again.
The pull brings their commits down and merges them with yours, so your branch now contains both lines of work and the push no longer threatens to leave anything behind.
The tempting wrong answer is to force-push, which overrides the check by overwriting the remote branch with your version. That erases the teammate's commits from shared history, which is the cardinal team sin and the reason unit 9 spends time on when rewriting is and is not acceptable.
git pull is really two Git operations performed back to back: fetch and then merge.
The fetch downloads the remote's new commits, and the merge folds them into your current branch, which is why a pull can produce a fast-forward, a merge commit, or a conflict depending on what each side did.
Seeing pull as a compound command explains its behavior and also its risk, since the merge half runs immediately whether or not you were ready for it. The next lesson shows why running the two halves separately is sometimes exactly what you want.