Building Apps with AILesson 41 of 87

Contents

Building Apps with AI

Lesson 41 of 87. Sign in to keep your place.

Module 5 · Save points, and shipping to a stranger

GitHub, and what a remote is for

9 min read

A remote is just another copy

Git on your laptop is complete. A remote is a second copy of the same history somewhere else, and origin is the conventional name for the main one. Nothing about it is special; you could have a remote on a USB stick.

GitHub is the most used host, and GitLab, Codeberg and Bitbucket do the same job. All of them offer free private repositories, which is the default you want until you decide otherwise.

Bash
git remote -v                                     # what remotes exist
git remote add origin git@github.com:you/app.git  # attach one
git push -u origin main                           # send main, remember the pairing

The -u sets up tracking so that later git push and git pull know where to go without being told.

Getting in

GitHub stopped accepting passwords for git operations in 2021. A push that asks for a password and rejects the correct one is this: it wants a personal access token, or an SSH key. The simplest route is the GitHub command-line tool, gh auth login, which walks through either. Do it once per machine.

Push, fetch, pull

git push sends commits the remote does not have. It only succeeds if your branch contains everything the remote’s branch contains: your history must be a continuation of theirs. When it is not, you see rejected: non-fast-forward. Something has been added on the remote that you do not have: you pushed from another machine, you edited a file in the web interface, or an automated tool committed. The fix is to bring those commits down first.

git fetch downloads the remote’s commits without touching your files. It is always safe, and it lets you look before merging: git log main..origin/main shows what is there that you lack.

git pull is fetch followed by merge. It is what most people run, and the merge can conflict like any other.

After a fetch, git status reports things like “ahead by 2, behind by 1”. Ahead: commits you have not pushed. Behind: commits you have not pulled. origin/main in that output is your last known view of the remote’s branch, updated only when you fetch.

A new machine

Bash
git clone git@github.com:you/app.git
cd app
npm install
cp .env.example .env    # then fill it in by hand

The last line is the one that gets forgotten, because .env is ignored by design and so it is the one thing the clone does not carry. An app that fails on a fresh clone with a configuration error is almost always this.

Pull requests when you are alone

A pull request is a proposed merge shown as a diff, in a browser, with a comment box. It exists for teams, and it is worth using by yourself, for one reason: it puts the whole of a change on a different screen from the one you built it on, all at once, file after file, with a preview deployment attached.

Reading an agent’s day of work that way catches things the editor did not: the file you never opened, the dependency added in package.json, the migration nobody mentioned. Push the branch, open the PR, read it, merge with the button, and git pull on your machine to catch up.

GitHub will also show an automated review from a model on the PR if you turn it on. Treat that as a second reader who has not run the app, which is what it is. It finds real things and it misses the things this course teaches you to test for.

Public or private

A public repository is readable by anyone and indexed within minutes. Bots scanning for keys find a committed secret faster than you can rotate it. Keep repositories private by default and make one public as a deliberate act, after checking the whole history rather than the current files:

Bash
git log -p | grep -iE "sk-|api[_-]?key|password" | head

If that finds anything, the key has to be revoked at the provider, because rewriting history to remove it is both hard and pointless once it has been pushed.

What a remote is not

It is not a backup of uncommitted work; only commits travel. It is not the deployment, though the host watches it and deploys on push, which is the next lesson but one. And it is not a substitute for your local copy: if GitHub is unavailable for an hour, you keep working, because git on your machine never needed it.

Every lesson here is open. Your progress is recorded once you pass the Building with AI exam.

Check your understanding

git push fails with ‘rejected: non-fast-forward’. What has happened?

Pick the one you would defend. Your answer stays private.

Next lesson · 7 minMerge conflicts without panic

Stuck on something?Ask Beatriz, your AI tutor

How to cite: Addaly (2026) ‘GitHub, and what a remote is for’, in Building Apps with AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/building-apps-with-ai/github-and-the-remote (Accessed: 13 October 2026).