Git Workflows and Project Best Practices

The final chapter of the Git and GitHub for Beginners series zooms out from individual commands to team habits. A workflow is simply an agreed set of rules about where commits go and how they reach main; picking one and following it is what makes a repository readable six months later.

Popular workflows at a glance

You do not need to master them all — feature branches plus pull requests, the GitHub flow core, will carry you through most of your career. The worst workflow is not a simple one; it is an inconsistent one.

Commit messages as project memory

Treat the log as documentation you can query. Beyond the imperative-mood habit from Staging and Committing, many teams adopt Conventional Commits: a typed prefix such as feat:, fix:, docs:, refactor:, test: or chore: followed by a short summary. Tooling then reads the history directly — generating changelogs, deciding whether a change is breaking, or triggering a release. Whatever style you choose, keep it uniform, keep subjects short, and make each commit one logical change so git log, git blame and git revert all tell a true story.

Protecting main and letting machines help

Teams that ship confidently put rules between good intentions and a bad merge. On GitHub you can require pull requests before merging, require a minimum number of approving reviews, require status checks to pass, and forbid force-pushes to main. The checks themselves come from GitHub Actions — workflow files in .github/workflows/ that run tests, linters and builds on every push and pull request. With protection on, the only way into main is a reviewed, tested branch, and nobody has to remember to be careful.

What belongs in the repository

• Commit: source code, configuration with fake values, migration files, your .gitignore, small assets and the README.
• Never commit: secrets and real .env files, dependencies (node_modules), build output (dist), editor folders and OS junk (.DS_Store).
• Optional but valuable: pre-commit hooks (via tools like Husky) that lint before every commit, and a .gitattributes for consistent line endings across Windows and macOS.

A leaked key is an emergency: rotate the secret immediately, then decide whether history needs scrubbing — which is exactly the kind of job you met in Correcting History. Mark releases with annotated tags (git tag -a v1.0.0) so the world can always find the exact commit a version came from.

Habits that keep a repository healthy

• Commit small, often and with purpose — a clean history is built, not rescued.
• Pull before you start, push before you stop — keeps divergence tiny and reviews fresh.
• Delete branches the moment they merge — the branch list should mirror active work.
• Run git status before every commit — thirty seconds that prevents accidental commits.
• Read other people's repositories — public projects on GitHub are free lessons in structure and workflow.

git log --graph --oneline --decorate -6

Expected output:

* 7a8b9c0 (HEAD -> main, origin/main) Update the menu prices
| * 3f4e5d6 (feature-online-orders) Add the order form validation
| * 1d2e3f4 Start the online orders page
|/
* 4c3b2a1 Fix the broken link in the footer
* 7e6d5c4 Style the navigation bar
* b2a1f0e Initial commit

git tag -a v1.0.0 -m "First public release"
git push origin v1.0.0

Expected output:

To github.com:sara-bakery/bakery-site.git
 * [new tag]         v1.0.0 -> v1.0.0

Common mistakes

• No workflow at all — everyone commits where they like and main becomes a guessing game.
• Committing secrets and pushing them — history remembers, so rotate the key first and only then worry about scrubbing.
• Long-lived branches treated as backups — a branch is a line of work, not storage; merge or delete it.
• Skipping CI because “it is a small change” — small changes are exactly what break production.
• Mixing several workflows in one repository — pick one, document it in the README, and keep it consistent.

Practice checklist

1. Read the workflow table again and write two sentences describing the workflow your current project follows (or should).
2. Convert your next three commit messages to Conventional Commits style and check them with git log --oneline.
3. Add a .gitignore entry for every junk file you have accidentally committed so far.
4. Create an annotated tag on a milestone commit and push it with git push origin <tag>.
5. Draft a branch-protection rule set (reviews plus passing checks) you would apply to main on a real team.

What's next?

You have travelled from “what is a snapshot?” to shipping reviewed, tagged, protected code — the complete beginner's arc. Revisit any chapter from the tutorials index whenever you need a refresher, and when your Git habits feel solid, continue your learning with JavaScript Best Practices and Next Steps to grow the projects you can now version with confidence.