GitHub push and pull, step by step

GitHub scares people with vocabulary more than mechanics. Push and pull are two directions of the same pipe: download what the team already merged, and upload what you just finished. This is the daily loop we use on Laravel, Vue, and static sites.

Before you touch code

Create a GitHub account and add an SSH key (or use HTTPS with a personal access token).
Get invited to the repo. Without access, clone fails and it is not “Git’s fault.”
Install Git and open a terminal in the folder where you want the project.

Clone (the first time)

On the repo page, copy the SSH URL ([email protected]:org/repo.git) and run:

git clone [email protected]:org/repo.git && cd repo

That creates a local copy tied to a remote named origin. After that you do not clone again. You update.

Pull: download everyone else’s work

At the start of the day, and again before you open a pull request:

git checkout main && git pull origin main

If you work on a branch, update main first, then merge or rebase. A pull with uncommitted local changes will stop you: stash or commit. Do not ignore the warning.

Push: upload yours

git status to see what changed.
git add the files that belong (never .env).
git commit -m "present-tense message: fix the quote form".
git push origin your-branch

The first time the branch does not exist on GitHub, Git suggests --set-upstream. Take it. Then open the pull request on github.com, ask for review, and do not push straight to main unless the team has that rule in writing.

When it goes wrong

Conflicts are not a moral failure. Open the file, find the <<<<<< marks, keep the right code, git add, continue. If you pushed too far, do not force-push main. On your own branches, coordinate before rewriting history.

If your team still ships ZIP files over WhatsApp, this loop is already an upgrade. Next: small PRs, one reviewer, and a deploy that does not depend on “I uploaded it last night.”