What Is GitHub? Repos, Git vs GitHub and Secrets

What is GitHub? GitHub is a website and platform that stores your code online in Git repositories. Every change is saved as part of a history you can go back to, and on top of that GitHub adds tools to review code, track work, run automated tests and deploy. If Lovable, Bolt or Cursor asked you to "connect GitHub," this is where your app's code now lives.

By Gary, Greenlight My App. Checked Nov 2, 2026. How we checked this: we read GitHub's docs on Git, repositories, ignoring files, secret scanning, push protection and Actions secrets, plus github.com/pricing, on Nov 2, 2026, and quote them below. Our team also ran the local Git steps below in a throwaway demo repo on Nov 2, 2026, pushing to a local stand-in remote rather than creating a repo on GitHub.com; the terminal screenshots are from that run. Drafted with AI tools and reviewed by a person before publishing.

What is GitHub?

GitHub is a cloud platform for storing and working on code. It hosts your projects as Git repositories, keeps the full history of every change, and adds pull requests for code review, issues for tracking work, Actions for automation, and links to hosts that deploy your app. It's free for individuals, with paid plans for teams.

GitHub's own docs (external) put it broadly: "GitHub is a platform that supports your entire software development process, from planning work to deploying and operating software."

You don't need to be a professional developer to use it. If an AI app builder created a repo for you, you're already a GitHub user. What matters most is knowing what's in that repo and who can see it.

What is Git? Git vs GitHub

Git is free, open-source version control software that runs on your computer. It records snapshots of your files (commits) so you can see what changed, undo mistakes and merge work from others. GitHub is a company and website that hosts Git repositories online. You can use Git without GitHub, but GitHub is built on Git.

From GitHub's docs: "Git is a version control system that tracks changes to files. It lets you work on your own copy of a project, record a history of your changes, and merge your work with other people's changes safely." And: "GitHub builds on Git by hosting your Git projects, called repositories, in the cloud, as well as adding planning and collaboration tools."

What is Git in full? It isn't an acronym. Git is just the name of the tool.

What is Git for Windows? It's the Windows build of Git, which also installs a terminal called Git Bash so the same commands work on Windows as on Mac and Linux.

What is a GitHub repository?

A GitHub repository, or repo, is one project's folder on GitHub: all its code and files plus the full history of every change. Each repo has its own settings, its own visibility (public or private), its own collaborators, and its own secrets for automation. Most apps live in one repo.

GitHub's repository docs (external) say: "A repository contains all of your code, your files, and each file's revision history. You can discuss and manage your work within the repository."

A few words you'll see in every repo:

• Commit: a saved snapshot of changes, with a message describing them.
• Branch: a separate line of work. main is usually the live version.
• Pull request: a request to merge one branch into another, where changes get reviewed.
• Clone: a copy of the repo on your own computer.
• Push / pull: sending your commits up to GitHub, or bringing others' commits down.

The important part for safety: history is permanent by default. Delete a file in a new commit and it's gone from the latest version, but still sitting in every earlier commit. That's why a key that was ever committed has to be treated as leaked.

What is GitHub used for?

GitHub is used to store and back up code, track every change, review work before it goes live, collaborate with others, run automated tests and deployments, host documentation and simple websites, and share open-source projects. For people building with AI tools, its main job is usually being the place your host deploys from.

GitHub's docs list the most common reasons, including: "Store and manage code with version control," "Collaborate and socialize on projects," "Contribute to open source software," "Automate software development workflows like CI/CD, testing, and deployments" and "Host documentation and websites."

For a typical vibe-coded app, the flow looks like this:

1. You (or your AI tool) change code.
2. The change is committed and pushed to GitHub.
3. Your host sees the new commit and deploys it.
4. The host reads your keys from its own environment variable settings, not from the repo.

How to use GitHub (make your first repository)

To make your first GitHub repository: create a free account, click New repository, name it, choose Private, and create it. Then, on your computer, initialize Git in your project folder, add a .gitignore that lists .env, commit your files, and push them to the new repo. It takes about ten commands.

Step 1: create the repo on GitHub. Sign in, click the + menu, choose New repository, give it a name, select Private, and click Create repository.

Step 2: set up Git in your project folder. If Git is new on this computer, tell it who you are first:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Step 3: keep secrets out before the first commit. Create a .gitignore file in the project root that lists your env files and dependencies:

.env
.env.local
.env*.local
node_modules/

GitHub's ignoring-files docs (external) explain: "You can create a .gitignore file in your repository's root directory to tell Git which files and directories to ignore when you make a commit."

Step 4: commit. Initialize the repo, stage everything, then check what's staged before committing:

git init
git add .
git status
git commit -m "First commit"

Read the git status output. If .env appears in the list of files to be committed, stop and fix .gitignore before you commit.

What this looked like in our demo repo. We made a tiny app with a fake key (API_KEY=XXXX) in .env and a .gitignore listing .env, .env.* and node_modules/. git status --short --ignored marked .env with !!, which means ignored, and git check-ignore -v .env named the exact .gitignore line doing it:

Step 5: connect and push. Use the URL GitHub shows on your new repo's page (YOUR-NAME/YOUR-REPO below is a placeholder):

git branch -M main
git remote add origin https://github.com/YOUR-NAME/YOUR-REPO.git
git push -u origin main

Step 6: check the repo page. Refresh it on GitHub. You should see your files, and no .env.

In our demo, the first commit held exactly two files, and git ls-files after the push confirmed .env never went in:

After that, the daily loop is just three commands: git add ., git commit -m "what changed", git push.

How do I undo a bad change?

This is where Git earns its keep, especially after an AI tool rewrites half your app. First list recent commits to find the one that broke things:

git log --oneline -n 10

Then create a new commit that reverses it, using the short ID from that list (abc1234 is a placeholder):

git revert abc1234
git push

git revert doesn't rewrite history, so it's safe on a branch other people or your host already use. Your host deploys the reverted version like any other commit. One limit to remember: reverting a commit that contained a key doesn't un-leak the key. The old commit is still in history, so rotate the key anyway.

Public vs private repos: which should your app use?

For an app with real users, use a private repo unless you deliberately want to open-source it. A public repo is readable by anyone on the internet, including every past commit. A private repo is visible only to you and people you invite. Neither is a safe place for API keys.

GitHub's docs: "Public repositories are accessible to everyone on the internet. Private repositories are only accessible to you, people you explicitly share access with, and, for organization repositories, certain organization members."

The docs also warn that "Public repositories expose your codebase to everyone, increasing the risk that attackers might exploit vulnerabilities or access sensitive information," and recommend features like secret scanning and push protection. Even private repos need "strong access controls," per the same page.

Worked example. Say you build a booking app in Lovable and connect it to GitHub with a public repo. A month later you paste a Stripe test key into a config file and commit it. Even if you delete it in the next commit, anyone who opens the earlier commit can read it. With a private repo, the exposure is limited to collaborators, but the fix is the same: revoke the key and move it to environment variables. Public or private, the key never belonged in the repo.

Keeping secrets out of GitHub (.gitignore, GitHub secrets, secret scanning)

Keep secrets out of GitHub with three layers: a .gitignore that stops .env files from being committed, environment variables on your host (or GitHub Actions secrets) to hold the real keys, and GitHub's secret scanning and push protection to catch mistakes. If a key does reach GitHub, revoke it first, then clean up.

Layer 1: .gitignore

The .gitignore from Step 3 is your first line of defense. One catch from GitHub's docs: "If you want to ignore a file that is already checked in, you must untrack the file before you add a rule to ignore it." The command they give:

git rm --cached .env

That stops tracking the file going forward. It doesn't remove it from history, and it doesn't make a leaked key safe. For what to do next, read committed a .env file to Git?. New to env files? Start with what is a .env file.

Layer 2: GitHub Actions secrets

If your GitHub Actions workflows need a key (to deploy, run tests or call an API), store it as an encrypted secret instead of in a file. On the repo page: Settings > Secrets and variables > Actions > New repository secret. Or with the GitHub CLI:

gh secret set DEPLOY_TOKEN
gh secret list

Per GitHub's docs, "The CLI will prompt you to enter a secret value," so you don't type it into the command itself. Reference it in a workflow as ${{ secrets.DEPLOY_TOKEN }}.

Two safety notes from GitHub's Actions secrets docs (external): "secrets are not passed to the runner when a workflow is triggered from a forked repository" (except the built-in GITHUB_TOKEN), and "Avoid passing secrets between processes from the command line."

For keys your running app uses, the place is usually your host's environment variable settings, not GitHub. GitHub secrets are for workflows that run on GitHub.

Layer 3: secret scanning and push protection

GitHub watches for keys too. Per its push protection docs (external), "Push protection is a secret scanning feature designed to prevent hardcoded credentials, such as secrets or tokens, from ever being pushed to your repository." Push protection for users "Is enabled by default" and "Stops you from pushing secrets to public repositories on GitHub."

Secret scanning (external) goes further back: it "scans your entire Git history on all branches of your repository for hardcoded credentials." For public repositories, "Secret scanning runs automatically for free." For organization-owned private repos, it's "Available with GitHub Secret Protection enabled on GitHub Team or GitHub Enterprise Cloud."

If push protection blocks your push, it offers bypass reasons including "It's used in tests," "It's a false positive" and "I'll fix it later." Don't pick "I'll fix it later" for a real key. Remove it from the commit instead.

What happens if I push my .env to GitHub?

Treat every key in it as leaked. GitHub's advice on a secret scanning alert: "rotate the affected credential immediately." In order:

1. Revoke or rotate each key in the provider's dashboard (Stripe, Supabase, OpenAI and so on). A new key is the only real fix.
2. Put the new keys in your host's environment variables, not in the repo.
3. Untrack the file with git rm --cached .env and add it to .gitignore.
4. Check the provider's logs and bills for use you don't recognize.
5. Clean history if you need to, but only after rotating. Forks and clones may already have a copy.

Specific guides: Supabase service role key exposed and AI API key stolen.

Connecting Lovable, Bolt or Cursor to GitHub safely

When an AI builder asks to connect GitHub, it's asking for permission to create and write to repos in your account. Before you approve, read the permissions screen, give access only to the repos it needs when that option is offered, choose private for the new repo, and check the first commit for .env files or hard-coded keys.

A safe connection checklist:

• I read GitHub's authorization screen and know what access I'm granting
• Where GitHub offers Only select repositories, I picked just this app's repo
• The new repo is Private
• I opened the first commit and searched it for .env, key, secret and token
• Real keys are in my host's environment variables, not in code
• Two-factor authentication is on for my GitHub account

You can review or remove an app's access later from your GitHub account settings, under the applications section. If you stop using a builder, revoke its access.

AI tools sometimes write keys straight into code to make a feature work. Search your repo for patterns like sk-, sk_live_, service_role and apikey after each big AI change. For builder-specific steps, see our Lovable launch security checklist, Bolt.new launch checklist and Cursor security checklist.

Which files should never go in a GitHub repo?

A quick reference you can keep next to your editor:

A committed .env.example is the polite way to tell collaborators (and your AI tool) which variables exist without sharing any values:

STRIPE_SECRET_KEY=XXXX
SUPABASE_URL=XXXX

GitHub's checks cover the repo. Your live site is a separate question: a key can still end up in the JavaScript your host serves. On Nov 2, 2026 our team ran Greenlight My App's free scan on our own demo deploy. It reported no secret keys in the public code and no exposed .env or .git files, and it flagged missing security headers to fix.

Is GitHub free?

Yes. GitHub Free costs $0 and includes unlimited public and private repositories, 2,000 CI/CD minutes a month and 500MB of Packages storage, per github.com/pricing (external) on Nov 2, 2026. Paid plans start at $4 per user per month for Team and $21 per user per month for Enterprise.

Prices as of Nov 2, 2026. Check the official page before you rely on them.

GitHub Secret Protection, which turns on secret scanning for private organization repos, is listed as its own add-on on the pricing page; check there for current terms. For most solo builders, Free is enough.

FAQ

What is Git and how to use it? Git is free version control software that records snapshots of your files. Use it with git add, git commit and git push to save and share changes.

What is Git in full? It isn't an acronym; Git is simply the tool's name. It's free, open-source version control that runs on your own computer.

Is it free to use GitHub? Yes. GitHub Free costs $0 with unlimited public and private repos and 2,000 CI/CD minutes a month (checked Nov 2, 2026). Team and Enterprise are paid.

What is Git for Windows? The Windows version of Git. It also installs Git Bash, a terminal that runs the same Git commands as on Mac and Linux.

What happens if I push my .env to GitHub? Treat every key in it as leaked. Revoke and replace each key first, move the new ones to your host's environment variables, then untrack the file.

Should my repo be private? For an app with real users, yes, unless you mean to open-source it. But private isn't a vault: keys still don't belong in any repo.

What is the difference between Git and GitHub? Git is the tool on your computer that tracks changes. GitHub is the website that hosts Git repositories and adds collaboration tools.

What is a GitHub repository? One project's folder on GitHub: all its code, files and full change history, with its own settings, collaborators and visibility.

Shipped your repo to a live site? Run a free scan with Greenlight My App to check your live site's public code for exposed API keys and missing security headers.