Keep a copy of your code on GitHub

What you need first

You need a GitHub account. A new empty repository is the easiest start.

• A GitHub account.
• A repository, ideally empty and private to begin with.
• A decision about who else gets access to it.

01 · Decide why you want it

Two good reasons: you want a copy that does not depend on us, or a developer is going to work alongside you. If neither applies yet, this can wait — nothing else needs it.

02 · Connect the repository

Authorise access from the project's GitHub screen and pick the repository. The access token is used and never written into the stored connection record, so a leak of that record cannot hand over your account.

03 · Read the state

The screen always shows one of five states, and it is worth knowing what each means.

• In sync — both sides match
• Ahead — you have changes here that are not there yet
• Behind — there are changes there you do not have here
• Conflict — both sides changed the same thing
• Disconnected — the link is broken or was removed

04 · Send your changes over

Push from the project screen when you are at a point worth keeping. Your history on GitHub then reads like a series of steps rather than one enormous dump, which is what makes it useful to a developer later.

05 · Deal with conflicts deliberately

When both sides changed the same file, the screen says which files and why rather than picking a winner. Look at both versions and decide. Automatic merging here would silently throw away somebody's work.

If you get stuck

Do I need this to publish? No. Publishing does not go through GitHub. This is for keeping your own copy and for working with a developer.

Can a developer work directly in the repository? They can, and then the project here will read as behind. Bring those changes in before you carry on, or you will be editing two versions of the same app.

Is my token stored? The stored connection record has no field that can hold it. That is a structural limit, not a promise about how carefully we handle it.