What is a full-stack git workflow?
It is how you manage changes that often span the client and server at once: a feature branch, commits that keep both halves consistent, a pull request, and a merge that deploys. Full-stack changes frequently touch multiple layers in one unit of work, so the workflow has to handle that cleanly.
Why it matters
A full-stack feature is usually one logical change across several files and layers. A disciplined git workflow keeps those changes coherent, reviewable, and revertible. Sloppy git — giant mixed commits, broken intermediate states — makes collaboration and rollback painful exactly when you can least afford it.
What to learn
- Feature branches and pull requests
- Commits that keep client and server consistent
- Writing clear PR descriptions
- Code review across both halves
- Keeping main always deployable
- Resolving conflicts
- Reverting a full-stack change safely
Common pitfall
Committing a client change and its matching server change separately in a way that leaves intermediate commits broken — the client expects an API that does not exist yet at that commit. Keep related cross-layer changes together so every commit on main is in a working state, which keeps bisecting and rollback sane.
Resources
Primary (free):
- Pro Git (free book) · docs
- GitHub — About pull requests · docs
- Conventional Commits · docs
Practice
Build a small feature that touches both client and server on one branch, keeping commits coherent so each is in a working state. Open a PR with a description covering both halves. Practice reverting the merge cleanly. Done when main stays deployable at every commit on your branch.
Outcomes
- Manage cross-layer changes on a feature branch.
- Keep every commit on main in a working state.
- Write clear PRs spanning client and server.
- Revert a full-stack change safely.