In this lesson, you will learn how to implement a pre-push checklist to guarantee your local code is production-ready before it ever touches the remote repository.
As you advance in your development career, the cost of breaking a remote build increases. If your project relies on continuous integration (CI) to validate builds, pushing broken code wastes time and resources. Instead of relying on the server to catch your mistakes, you can treat your local development environment as the final "gatekeeper" by standardizing a pre-push verification process.
The Pre-Push Checklist
Before you run git push, you should ensure your workspace is clean and functional. A robust checklist typically includes:
- Running the Test Suite: Ensure your unit and integration tests pass.
- Linting and Formatting: Verify that your code adheres to project style guidelines.
- Dependency Checks: Check for outdated or insecure packages.
You can automate this verification by creating a simple shell script or a Makefile in your root directory. For example, a verify.sh script might look like this:
#!/bin/bash
echo "Running tests..."
npm test || exit 1
echo "Running linter..."
npm run lint || exit 1
echo "Verification passed! Ready to push."
Integrating into your Workflow
While you can execute these commands manually, the most effective workflow is to cultivate the habit of running your verification script every time you finish an atomic commit or before you finalize a feature branch.
If you are working on a team, you might also consider Git hooks. By adding a script to .git/hooks/pre-push, you can instruct Git to execute your verification logic automatically. If the script exits with a non-zero status, Git will physically block the push command, protecting the remote repository from potential breakage.
By formalizing these checks, you transition from "hoping" your code works to "knowing" it meets your project's standards, significantly reducing the friction in your collaboration workflow.
Key Takeaway: Implement a non-negotiable pre-push checklist—consisting of tests and linting—to ensure that only verified, stable code ever reaches your remote repository.