Working with Remotes and GitHub

Everything so far has lived entirely on your own computer. A remote is a copy of the repository hosted elsewhere — most commonly on GitHub, GitLab, or Bitbucket — that lets you back up your work and collaborate with other people.

Connecting to a remote

git remote add origin https://github.com/yourname/your-repo.gitngit remote -v            # confirm it was added correctly

origin is just a conventional name for “the main remote” — you could call it anything, but virtually every project follows this convention, so straying from it without a good reason just confuses collaborators.

Pushing and pulling

git push origin main       # send your local commits to the remotengit pull origin main       # fetch and merge remote changes into your local branch

push sends your commits up; pull brings other people’s commits down. A very common early habit worth building: git pull before you start new work each day, so you are building on the latest version rather than an outdated one.

Cloning an existing repository

git clone https://github.com/yourname/your-repo.git

clone downloads a complete copy of a repository — including its entire history, not just the current files — and automatically sets up origin for you, ready to push and pull from immediately.

.gitignore

# .gitignorennode_modules/n.envn*.log

A .gitignore file tells Git which files and folders to never track — dependency folders that can be reinstalled, environment files containing secrets like API keys, and generated log files are the classic examples. Committing secrets to a public GitHub repository by accident is a genuinely common, genuinely serious mistake — a .gitignore from the very first commit is cheap insurance against it.