← Back to the journal Developer utilities

Safe developer utility commands for MySQL, tar, Git, PHPCS, and PHPStan

A categorized terminal reference for database backups, archive inspection, Git diffs, code-quality checks, and pre-commit hooks without leaking credentials.

8 August 202610 min readOpsinTech Product & Engineering Team

Editorial image for Safe developer utility commands for MySQL, tar, Git, PHPCS, and PHPStan — Developer utilities / OpsinTech insight

Step 1: export and restore MySQL safely

Keep passwords out of the command line: use --password without a value so MySQL prompts for it. Treat dump files as sensitive because they can contain personal and production data.

Export a database

Creates a logical SQL backup while prompting for the database password.

mysqldump --host=<db-host> --user=<db-user> --password <database> > backup.sql

When to use itUse a timestamped filename and store it in an access-controlled backup location.

Inspect before importing

Checks that the file is non-empty and lets you review its header before execution.

wc -l backup.sql
head -n 20 backup.sql

When to use itConfirm the source database and dump format without exposing the whole file.

Restore a database

Executes the SQL dump against the selected database.

mysql --host=<db-host> --user=<db-user> --password <database> < backup.sql

When to use itUse only after confirming the host, target database, backup age, and rollback plan.

CautionDestructive: an import can overwrite or conflict with existing data.

Step 2: create and inspect tar archives

List unfamiliar archives before extraction. Extract into a dedicated directory so files cannot unexpectedly mix with the current project.

Create a compressed project archive

Archives the current directory while excluding regenerable cache directories.

tar -czf project-backup.tar.gz --exclude='./var/cache' --exclude='./var/page_cache' .

When to use itAdd project-specific exclusions for logs, generated files, secrets, and large dependencies.

List archive contents

Prints paths stored in a gzip-compressed tar archive without extracting them.

tar -tzf project-backup.tar.gz

When to use itCheck path layout and look for unexpected absolute or parent-directory entries.

Extract to a chosen directory

Extracts the archive into an explicitly selected directory.

tar -xzf project-backup.tar.gz -C <destination-directory>

When to use itCreate a temporary destination, inspect the result, then move only intended files.

Step 3: inspect Git changes and commits

These commands are read-only. Use the operating system’s secure credential manager; do not enable plaintext credential storage in shared setup instructions.

Review working-tree state

Shows changed paths, unstaged changes, and staged changes separately.

git status --short
git diff
git diff --staged

When to use itRun all three before committing so unrelated or sensitive files are not included.

Inspect one commit

Displays a commit’s metadata and patch.

git show <commit>

When to use itReplace the placeholder with a reviewed branch, tag, or abbreviated commit identifier.

Compare a path between revisions

Limits a revision comparison to the specified file or directory.

git diff <older-commit> <newer-commit> -- <path>

When to use itUse to review how one module changed between two releases.

Step 4: run PHP code-quality checks

Install tools as project development dependencies and pin their versions in composer.lock so local and continuous-integration results agree.

Run Magento coding standards

Checks a module against the installed Magento coding-standard rules.

vendor/bin/phpcs --standard=Magento2 <module-path>

When to use itTarget the changed module first, then run the repository’s complete quality command.

Run PHPStan

Performs static analysis at the selected configured rule level.

vendor/bin/phpstan analyse <source-path> --level=<level>

When to use itUse the level already agreed in phpstan.neon; raise it deliberately rather than bypassing errors.

Run Composer validation

Checks composer.json and its lock-file relationship.

composer validate --strict

When to use itRun after any dependency or Composer metadata change.

Step 5: use a focused pre-commit hook

A pre-commit hook should be fast and deterministic. Keep the complete test matrix in continuous integration, where results are shared and enforceable.

Make the hook executable

Allows Git to execute the local pre-commit hook.

chmod +x .git/hooks/pre-commit

When to use itRun after creating or copying the hook on Linux or macOS.

Minimal hook pattern

Stops a commit when Composer validation or the project PHPStan command fails.

#!/bin/sh
set -eu
composer validate --strict
vendor/bin/phpstan analyse

When to use itSave as .git/hooks/pre-commit, then add project-specific fast checks.

CautionHooks are local by default. Mirror required checks in continuous integration.

Step 6: avoid copied destructive shortcuts

Do not paste broad DELETE statements, disable foreign-key checks, run recursive 777 permissions, or bypass dependency platform requirements. Restore a reviewed local fixture, fix ownership correctly, and resolve runtime compatibility instead.

Preview dependency resolution

Shows the dependency changes Composer would make without modifying installed packages or lock data.

composer update --dry-run

When to use itUse before an upgrade and resolve reported PHP or extension constraints.

Confirm the target directory

Shows the current path and repository state before a filesystem or database operation.

pwd
git status --short

When to use itMake this a habit before any command copied from documentation or a ticket.

REF