Git, GitHub, Branches, and Recovery

Git is a version control system on your computer. GitHub is an online service for storing and collaborating on Git repositories. They are related but different. You can use Git without GitHub, and a change does not exist on GitHub until you push it.

1. Prepare Git and the Repository

Install Git from git-scm.com, then verify it:

git --version

Configure commit identity once on a personal computer:

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

Open the correct project folder in your IDE and inspect its status. If it is not yet a repository, run git init. Never initialise a broad Downloads, Documents, or parent folder that contains unrelated projects.

2. Create the First Checkpoint

Before a coding agent edits the project, save a recoverable baseline:

git status
git add .
git commit -m "chore: create project baseline"

Inspect the file list before git add .. Environment files, credentials, database backups, and secrets must not be committed. Add appropriate patterns to .gitignore, then inspect the status again.

A commit is a local checkpoint, not a cloud backup. Push it if you need the commit to exist on a GitHub remote.

3. Read Status and Diffs

Use these checks frequently:

git status --short
git diff
git diff --staged

Status lists changed files. The ordinary diff shows unstaged changes. The staged diff shows what will enter the next commit. Reviewing diffs reveals accidental files, debug logs, secrets, large deletions, and out-of-scope changes.

Do not treat an agent summary as a substitute for the diff. A summary helps navigation, while the diff is the actual evidence.

4. Use One Branch per Task

A branch separates a task from the primary branch:

git switch -c feature/login-validation

Choose a name that describes the outcome. Keep one reviewable change on each branch. After checks pass, push the branch and merge it through a pull request.

For beginners, one agent, one branch, and small commits are safer than parallel agents. Add worktrees only after you understand branches, merges, diffs, and file ownership.

5. Recover Mistakes Safely

Always inspect status and diff before recovery. The following command discards uncommitted changes in one file:

git restore path/to/file

Use it only when those changes are no longer needed. To unstage a file without deleting its content:

git restore --staged path/to/file

For a shared commit, git revert <commit> creates a reversing commit while preserving history. Avoid git reset --hard, force push, or branch deletion until you understand the exact target and effect.

6. Publish to GitHub

Use GitHub Desktop for a visual path, or use the command line. Create an empty repository on GitHub without an extra README when the local project already has commits, then connect the remote:

git remote add origin https://github.com/USERNAME/REPOSITORY.git
git push -u origin main

For a feature branch, push that branch and open a pull request. A private repository is recommended for practice involving internal requirements. Private visibility still does not make Git a safe place for secrets.

7. Resolve Merge Conflicts

A conflict means Git cannot select the final content automatically. Do not remove markers without understanding both sides. Compare the intended behavior, select or combine the changes, run tests, and stage the resolved file.

git status
git add path/to/resolved-file
git commit

When a conflict is broad, stop and ask the change owners to identify the source of truth. A green build is insufficient if the correct requirement disappeared.

8. Commit and Push Checklist

• Status contains only files that belong to the task.
• No environment files, tokens, private keys, user data, or large build output are included.
• You reviewed the diff, including relevant generated files.
• Repository lint, typecheck, tests, and build passed.
• UI changes were checked on desktop and mobile.
• The commit message describes the outcome.
• You are pushing the intended branch.