Git, GitHub, Backups, Secrets, and Safe AI Coding

Git records project history locally. GitHub can store a remote copy and support collaboration. Neither automatically protects database records, uncommitted files, ignored secrets, or external service configuration.

Initialize safely

From the exact project folder:

git init
git status

Before the first commit, create .gitignore. Framework generators usually provide one, but inspect it. Typical exclusions include:

node_modules/
.next/
.expo/
.env
.env.*
!.env.example
*.log
__pycache__/
.venv/

Rules vary by project. Do not paste a giant generic file that accidentally ignores source or lockfiles.

Understand the three views

Your working tree contains current files. The staging area selects changes for the next commit. A commit is a named snapshot in history.

Useful inspection commands:

git status --short
git diff
git diff --staged
git log --oneline -5

Read status and diff before every commit. Generated changes can include accidental lockfile replacements, deleted assets, or debug logs.

Make small commits

A good commit leaves the project working and describes one coherent result:

git add src/components/summary-card.tsx src/components/summary-card.test.tsx
git commit -m "Add accessible summary card"

Avoid staging everything blindly until you have reviewed the full status. Never ask an agent to commit if you have unrelated personal changes you have not identified.

Branches

A branch gives work a name without duplicating the folder manually:

git switch -c feature/category-filter

Branches are useful for risky or multi-step work, but they do not replace commits. An uncommitted broken branch is still hard to recover.

Undo without panic

Different problems require different recovery methods. Before any restore, reset, clean, or rebase command, inspect status and identify whether work is committed, staged, untracked, or only remote.

Use this prompt:

Do not change anything. Inspect Git status, recent commits, and the relevant
diff. Explain which work is committed, staged, modified, or untracked. Propose
the least destructive recovery option and what data it would discard. Wait for
my approval. Do not use reset --hard or clean.

Copying files out of the project or committing a safe checkpoint may be sensible before a complicated repair.

GitHub is a remote, not magic backup

Create a repository through GitHub's official interface, then follow its displayed remote commands. A push uploads committed history. It does not include ignored .env files, uncommitted work, your Supabase database, app-store settings, or local signing credentials.

For a private project, confirm repository visibility before pushing. Organization policies, collaborators, applications, and CI systems may still access private repositories according to configuration.

Back up databases with provider-supported exports or backups. Document infrastructure settings. Protect recovery codes and signing credentials outside the repository.

Secret handling

A secret includes database passwords, private API keys, service-role credentials, token-signing keys, app-store credentials, and access tokens.

Rules:

1. Store secrets in local or hosted environment settings, never source code.
2. Commit .env.example with fake or empty values.
3. Verify .gitignore before adding the first secret.
4. Use least-privileged credentials for each environment.
5. Rotate a secret immediately if exposed in a commit, log, screenshot, prompt, or issue.
6. Do not rely on deleting a commit; copies may already exist.

Publishable client keys are not administrative secrets, but their safety depends on server-side authorization such as RLS. Follow the provider's exact key guidance.

Review agent actions

Before approval, classify a command:

• Read-only: status, search, version, tests that do not modify tracked files.
• Local and reversible: focused source edits, installing a reviewed dependency, creating a branch.
• State-changing: migrations, deploys, pushes, account configuration, emails, or external APIs.
• Destructive: deletion, forced Git operations, dropping data, rotating production credentials.

The final two categories need exact targets, consequences, rollback, and explicit human intent.

Project instructions

Put durable safety guidance in the tool's project instruction mechanism:

Preserve user changes. Inspect before editing. Never commit secrets or .env
files. Do not run destructive Git commands. Ask before migrations, deploys,
remote pushes, or external state changes. Run lint, type checking, and tests;
report anything not run.

Use AGENTS.md for Codex, CLAUDE.md for Claude Code, or Cursor project rules as appropriate. A shared PROJECT.md can remain the human-readable source of truth.

Checkpoint exercise

1. Initialize a disposable repository.
2. Add a README and commit it.
3. Modify one sentence.
4. Inspect git diff.
5. Ask your agent to explain the diff without changing it.
6. Commit the correction.
7. View both commits with git log --oneline.

If you can see and explain both snapshots, you have a practical recovery foundation.

Completion checklist

• I inspect status and diff before commits.
• I make small working commits.
• I know GitHub excludes ignored and uncommitted data.
• Real secrets never enter source, prompts, logs, or screenshots.
• I ask for a non-destructive recovery plan before undo commands.

Next: Choose a Web Stack and Create the Project

Official references

• Git documentation
• GitHub authentication and security documentation