Pulling and Pushing Code

Once your repository is connected to GitHub, two of the most common remote operations are:

git push
git pull

A simple way to remember them is:

push → send local commits to GitHub

pull → bring GitHub changes to your computer

You will use these commands constantly in everyday development.

Your First Push

Suppose you already created a local commit:

git add .
git commit -m "Initial commit"

To upload your local main branch to GitHub for the first time, run:

git push -u origin main

This command has three important parts.

origin is the remote repository:

origin

main is the branch being pushed:

main

And:

-u

sets up a default tracking relationship between your local branch and the remote branch.

So:

git push -u origin main

roughly means:

Push my local main branch to origin, and remember that these two branches correspond to each other.

After the first push, you can normally use:

git push

for future updates.

Pushing a New Branch

Suppose you create:

feature/login

with:

git switch -c feature/login

Then you make changes and commit them:

git add .
git commit -m "Add login page"

The first time you push this branch, use:

git push -u origin feature/login

After that, while working on the same branch, you can normally just run:

git push

The branch will then also appear on GitHub.

What Is a Remote Branch?

The diagram below shows how local and GitHub branches correspond:

Local changes do not automatically appear on GitHub. You need to push them.

In the same way, changes created by someone else on GitHub do not automatically appear on your computer. You need to pull or otherwise fetch them.

Using git pull

To get the latest changes for your current branch, run:

git pull

Git will get the latest remote commits and try to integrate them into your current local branch.

If you are on:

main

and run:

git pull

Git will normally update your local main with the latest remote main.

You can think of it as:

GitHub main → git pull → Local main

Why Pull Before Pushing?

Suppose you and another developer both start from the same commit:

A

The other developer pushes a new commit first:

A → B

Meanwhile, your local history looks like:

A → C

If you try to push immediately, Git may reject the push because the remote contains commit B, which your local branch does not have.

You first need to bring the remote work into your local branch:

git pull

Then resolve any merge if necessary, and finally:

git push

That is why team workflows often look like:

Get the latest remote changes → git pull → Continue work / resolve conflicts → git push

git pull Can Cause Conflicts

A pull is not guaranteed to succeed automatically.

If the remote branch and your local branch changed the same part of the same file, Git may encounter a merge conflict.

The resolution process follows the same conflict-handling idea introduced earlier:

git pull → Conflict → Review in VS Code → Choose the final code → git add → git commit

This is why understanding branches and merging makes remote Git workflows much easier to understand.

Push Is Not the Same as Saving

A common beginner mistake is to think that git push saves your work.

The command that creates Git history is:

git commit

while:

git push

only uploads commits that already exist.

So:

git commit → Create a commit → git push → Upload the commit

If you edit a file but do not commit it, running:

git push

will not upload those uncommitted changes.

A Simple Push Workflow

A practical everyday workflow might be:

git status

Check your changes, then:

git add .

Create a commit:

git commit -m "Fix login error"

Get the latest remote updates:

git pull

If everything is fine, push:

git push

The workflow is:

Edit code → git add → git commit → git pull → git push

This is not the only possible workflow, but it is a clear and safe starting point for beginners.