What you will learn
- Write clear commit messages that explain a change
- Keep each commit small and focused on one change
- Use a .gitignore file to exclude dependencies, build output and secrets
A commit history is only useful if you can read it. Write messages in the imperative, as if giving an instruction: "Fix menu button on mobile" rather than "fixed stuff". The first line should be short and say what the commit does. If more context helps, leave a blank line and explain why the change was needed. Future you, and your colleagues, will rely on this.
Keep each commit focused on one change. If you fix a bug and also restyle the footer, make two commits. Small commits are easier to review, easier to understand later and easier to undo without losing unrelated work. Before committing, run git diff --staged to check exactly what you are about to save, and remove any stray debugging code.
Some files should never be committed. A .gitignore file in the project root lists patterns for Git to skip. Typical entries are node_modules, which holds installed packages that can be reinstalled, build output folders, system files such as .DS_Store, and .env files containing passwords or API keys. Once a secret is pushed to a shared repository, treat it as exposed and change it.