Getting GitHub working, in order

Why now, You have decided you need it, so the account is the first real move.

Sign up on the free plan. It includes private repositories and unlimited collaborators, so there is nothing to buy at this stage. Use an email address that belongs to the business and that you will still control in five years.

This account will own the definitive copy of your software. Whoever controls the email controls the account.

Done when, You are signed in to GitHub on an account tied to a business email address.

You'll know it worked when sign out and sign back in to confirm you can actually get in unaided.

Why now, The account exists and is empty, which is the cheapest possible moment to secure it.

Enable two factor authentication, then save the recovery codes somewhere that is not your phone and not the same laptop. A password manager or a printed copy in a drawer both work.

Losing access to this account means losing the definitive copy of your software. The recovery codes are the only route back if the phone goes in a river.

Done when, Two factor authentication is on and the recovery codes are stored somewhere outside your phone.

You'll know it worked when open your stored recovery codes and confirm you can actually read them.

• Work out how to get back into your account

  Use this when you cannot sign in to the account that holds your code.

  Get back into the account that holds your software.

  Works through the official recovery routes in order of what you still control.

  Copy promptExpand

Why now, The account is live and secure, so the code has somewhere safe to land.

If a builder made your app, connect that builder to GitHub and let it create the repository. If you have code already, create an empty repository yourself. Either way, set it to private unless you have a specific reason to publish it.

Private is the right default for anything a business runs on. Public means the entire internet can read it, including anything careless left in the code.

Done when, One repository exists, it contains your code, and its visibility is set to private.

You'll know it worked when open the repository while signed out, in a private browser window. If you can read it, it is public.

• The builder that writes your code

  A two way connection between the tool that builds your app and the repository that stores it.

  It is what makes the GitHub copy real rather than a stale snapshot. Changes made in the builder arrive in the repository, and changes pushed to the repository arrive back in the builder.

  You get

  A live copy of your software in your own account, and the option to work outside the builder later.

  You'll need

  A GitHub account, and a project in the builder.

  Do this

  Connect the builder to GitHub from inside the builder and let it create the repository.

  Check it

  Make a change in the builder, then refresh the repository and see the change listed in the history.

  Then

  Check the repository visibility.

  Haven't got it? That's fine, The builder holds the only copy, and your access to your own software depends entirely on that account staying open to you.

  Read our take on Lovable
  Official instructions

  Official source · as of September 2026 · Two way sync documented on the builder's own integration page, verified 10 September 2026.

Why now, A repository now exists, so its visibility is a real state rather than an intention.

Open the repository settings and read the visibility setting. Change it if it is not what you intended.

Accidentally public code is the single most common and most expensive mistake here, and it is silent when it happens.

Done when, The visibility setting reads private, or you have deliberately chosen public and know why.

You'll know it worked when the repository page shows a private label next to its name.

Why now, This is the first thing that decides whether the rest of the path applies to you.

Answer one question honestly: does your business depend on software that was built for it, rather than bought off the shelf. If yes, GitHub belongs in your stack. If everything you use is somebody else's product, close this and come back when that changes.

GitHub stores and tracks code. With no code, it is an empty filing cabinet that makes you feel organised and does nothing else.

Done when, You can say in one sentence what code you have and where it currently lives.

You'll know it worked when if your answer is that a builder holds the only copy of something your business runs on, that is a yes.

• Decide whether you need GitHub yet

  Use this before you sign up for anything, while you are still deciding whether this belongs in your stack at all.

  Get a straight yes or not yet, in your own situation.

  Turns the general advice that everyone should use GitHub into an answer about your business.

  Copy promptExpand

Why now, Every later step uses these two words, so they need to mean something first.

Read the two short official pages: one explains that Git is the system that records every change, and the other explains that a repository is simply the folder those changes are recorded in. That is the whole idea.

Most people abandon GitHub because the words are unfamiliar, not because the tool is hard. Ten minutes here removes the fog.

Done when, You could explain to someone else what a repository is and what a commit records.

You'll know it worked when you can read the word commit without needing to look it up.

Why now, This applies the first time anyone other than you touches the code.

Applies when Only when someone other than you is going to work on the code.

When someone else needs to work on the code, invite them as a collaborator on the repository. Never share your own login. Remove their access the day the work ends.

Sharing a password gives away the account, the history and the ability to lock you out. An invitation gives away only the work.

Done when, The person you are working with has their own access and you have not shared a password.

You'll know it worked when the repository access list shows them by name, and shows you as the owner.

• Somebody else to work on the code

  A developer, contractor or colleague who will edit the software alongside you.

  The collaboration features exist for this and only this. Until there is a second person, none of it applies to you.

  You get

  Reviewed changes, separate access, and a record of who did what.

  You'll need

  A repository, and actual work to hand over.

  Do this

  When the day comes, invite them as a collaborator rather than sharing your login.

  Check it

  Their name appears in the repository access list and yours still shows as owner.

  Then

  Learn what a pull request is before they open one.

  Haven't got it? That's fine, You keep working alone, which is the normal state for most owners and costs you nothing.

  Official instructions

  Official source · as of September 2026 · GitHub's own collaborator invitation documentation, verified 10 September 2026.

• Hand the code to a developer without losing control

  Use this the first time somebody other than you is going to work on the code.

  Let someone work on the code without giving away the account.

  Produces the access to grant, how to grant it, and how to remove it when the work ends.

  Copy promptExpand

Why now, Once more than one person touches the code, changes stop being instant and start being proposed.

Applies when Only once you are working with a developer or a team.

Read the official page on pull requests. You do not need to run one today. You need to know the mechanism exists, so that when a developer says they have opened one, you know what you are being asked for.

This is where an owner stops being at the mercy of whoever is writing the code. A change proposed and reviewed is a change you can question before it reaches customers.

Done when, You can say what a pull request is and why you would want one.

You'll know it worked when a developer mentions a pull request and you know what to look at.