Push Local Changes to GitHub

Stage your work, commit with a clear message, and push to remote repository.

When to use

Use this when you have made local changes and are ready to share them by pushing to GitHub. Perfect for ongoing work, bug fixes, or feature updates.

Pre-flight checklist

You have made changes to files in your working directory.
The remote repository exists and you have push access.
Your changes have been tested locally (if applicable).

Steps

Check what files have been modified and review your changes.
```
git status
git diff
```
Stage the files you want to include in this commit. Use . to stage all changes, or specify individual files.
```
# Stage all changes
git add .

# Or stage specific files
git add src/components/Button.tsx README.md
```

Create a commit with a descriptive message that explains what and why.

git commit -m "feat: add responsive navigation component

- Implement mobile-friendly hamburger menu
- Add proper ARIA labels for accessibility
- Include smooth transition animations"

Push your changes to the remote repository.

# For existing tracking branch
git push

# For new branch or first push
git push -u origin feature-branch-name

Verification

git status shows "Your branch is up to date with 'origin/branch-name'".
Visit GitHub to confirm your changes appear in the repository.
Any CI/CD workflows should trigger if configured.

Common scenarios

Multiple commits: Repeat the add/commit cycle for logical groupings before pushing.
Sensitive files: Use .gitignore to exclude secrets, logs, or build artifacts.
Force push: Only use git push --force-with-lease if you're certain about rewriting history on a shared branch.

Follow-up

Create a pull request if working on a feature branch.
Check that any automated builds or deployments complete successfully.
Notify team members if the changes affect shared components or APIs.