What needs to be installed?

For most React, TypeScript, FileMaker integration, and web projects, you only need Git. GitHub CLI is useful but optional. Pick your computer below, do that setup, then continue with the same steps as everyone else.

git --version

git --version

xcode-select --install

brew install git

winget install --id GitHub.cli -e --source winget

gh --version

brew install gh

gh --version

Node.js, npm, and pnpm are separate JavaScript tools. If you already build React apps, you probably have what you need. Check with node --version, npm --version, and pnpm --version.

Keep your credentials out of the project

GitHub does not accept your normal account password for Git pushes. The easiest beginner setup is to use HTTPS and let Git Credential Manager or GitHub CLI open a browser sign-in.

If you installed GitHub CLI, run:

gh auth login

Choose GitHub.com, HTTPS, and browser authentication. When it finishes, check which account is active:

gh auth status

If you use both a personal account and a company account on GitHub.com, authenticate each account when needed and use:

gh auth switch

Create the online home for your project

A repository is the place where your project files and Git history live on GitHub. A GitHub App is a separate type of integration that acts on behalf of software. For the purpose of putting your project on GitHub, you want a repository.

After GitHub creates the repository, leave that browser page open. The Quick Setup area shows the repository URL that you will connect to your local folder.

Check what you are about to upload

Keep one project per folder. Before you connect it to GitHub, make sure the folder does not contain passwords, private keys, customer data, database exports, or a large generated folder such as node_modules.

Open a terminal in the project folder

On Windows, open the project folder in File Explorer, click the address bar, type powershell, and press Enter. Or use:

cd "C:\path\to\your\project"

On Mac, open Terminal and use the project folder path. If the folder is on your Desktop, it may look like this:

cd "/Users/yourname/Desktop/Your Project"

Check or create a .gitignore

For a typical React or Vite project, the important entries look like this:

node_modules/
dist/
build/
.env
.env.*
!.env.example
*.pem
*.key

It is fine to keep an .env.example file with empty example values and notes about what the project needs. Do not copy real values into it.

Run the project checks

pnpm install
pnpm build
pnpm lint

Use the commands listed in your own package.json if they are different. The point is to know that the project works before the first upload.

Initialize, commit, connect, and push

Run these commands from the project folder. If the folder is already a Git repository, git init is harmless and simply confirms it.

git init -b main
git config user.name "Your Name"
git config user.email "your-email@example.com"
git status
git add .
git status
git commit -m "Initial project version"

Now copy the HTTPS URL from your new GitHub repository. It should look like this:

https://github.com/OWNER/REPOSITORY.git

Connect your local folder to that online repository:

git remote add origin https://github.com/OWNER/REPOSITORY.git
git remote -v

If your project already has a remote called origin, use this instead:

git remote set-url origin https://github.com/OWNER/REPOSITORY.git
git remote -v

Finally, send the local main branch to GitHub:

git push -u origin main

The -u connects your local branch to the online branch so later you can usually type only git push. If Git asks you to sign in, complete the browser or credential-manager prompt. Do not type your GitHub account password into a terminal prompt.

What you will normally do after the first upload

Git is most useful when you make small, understandable checkpoints instead of waiting until the end of a large project. A commit is a saved point in the history. It is not a backup by itself until you push it to GitHub.

git status
git pull --rebase
# make and test your changes
git add .
git diff --cached
git commit -m "Describe the change"
git push

Examples of good commit messages include Add attendee search, Fix FileMaker connection error, and Update conference schedule. Git history is much easier to understand when each commit says what changed.

Give people access without making everything public

A private repository is visible only to its owner and the people or teams granted access. To add somebody, open the repository on GitHub and go to Settings, then Collaborators and teams or Manage access. Invite their GitHub username or email and choose the appropriate role.

• Read is enough to view and clone a repository.
• Write allows a person to push changes and open pull requests. This is usually the right role for a developer who needs to contribute.
• Maintain is for project management without the most sensitive administrative actions.
• Admin should be limited to people who need to manage access, repository settings, or deletion.

For an organization-owned project, the organization owner or a repository administrator may need to add people to a team or repository. Company policies can also limit who may create repositories or change a repository from private to public.

Use a branch for each piece of work

Two people can work on the same project at the same time if they work in separate branches. Keep main in a reasonably working state, then create a branch for a feature or fix:

git switch main
git pull --rebase
git switch -c feature/short-description
# edit and test
git add .
git commit -m "Add short description"
git push -u origin feature/short-description

Open a pull request on GitHub, review the changes, and merge it into main. If two people edit the same lines, Git may report a conflict. That is not a disaster. It means Git needs a human decision about which version, or combination of versions, should remain.

Let the agent help with the work, not with your passwords

Folder-based agents such as Codex can inspect a project, edit files, run checks, and explain a change. Put an AGENTS.md file in the project root so the agent knows the project rules. The companion file packaged with this guide is designed to be copied into a project and edited for that project.

A sensible agent workflow is:

1. Read AGENTS.md, the README, and the current Git status.
2. Confirm the requested work and create a task branch.
3. Make the smallest coherent change.
4. Run the relevant tests, lint, and build commands.
5. Show the changed files and the diff.
6. Commit or push only when the project owner explicitly asks.

Do not give an agent a private key, a GitHub token, a database password, customer data, or a production .env file. The agent can tell you exactly what to type after you authenticate locally.

Make a project public only after a deliberate review

Before changing a repository from private to public, review the current files and the Git history. Removing a secret from the latest version does not remove it from older commits. If a credential was ever committed, rotate it first and clean the history before publication.

For client work, integrations, internal tools, and projects with real data, keeping the repository private is usually the better default. Public code should have a clear README, a license where appropriate, and no private customer or infrastructure details.

Official links

• Git for Windows download
• GitHub CLI download
• Create a new GitHub repository
• GitHub: creating a repository
• GitHub: adding locally hosted code
• GitHub: organization repository roles
• Full Access conference website
• RGC Data LLC