The Git and GitHub for Beginners blog post covers the fundamentals - this lesson goes further into the workflows real teams actually use day to day.
Branching strategy: do not work directly on main
Professional teams almost never commit directly to the main branch. Instead, every feature or fix gets its own branch, reviewed and merged through a pull request:
git checkout -b fix-login-bug
# ... make changes, commit them ...
git push -u origin fix-login-bug
# then open a Pull Request on GitHub for review
Writing commit messages that are actually useful
"fixed stuff" tells a future reader nothing. A good commit message states what changed and, if not obvious, why:
git commit -m "Fix session timeout not clearing cart on logout"
Resolving a merge conflict
When two branches change the same lines, Git cannot merge automatically and marks the conflict directly in the file:
<<<<<<< HEAD
const price = 499;
=======
const price = 599;
>>>>>>> feature-branch
Edit the file to keep the correct version (or a merge of both), remove the conflict markers, then git add and commit as normal.
.gitignore: keeping secrets and clutter out of your repo
# .gitignore
node_modules/
.env
*.log
config/config.php
Never commit files containing real credentials or dependencies that should be installed fresh - a .gitignore file tells Git which files and folders to never track in the first place.