Project Scripts

The scripts every repository has, keeping secrets out of them, and sharing your own tool.

Updated November 10, 2026

In a Project

The Scripts Every Project Has (Journeyman): Most software projects keep a few small scripts for the same four jobs: setup.sh gets a computer ready, dev.sh runs the project while you work, test.sh checks it and deploy.sh puts it live, and setup.sh checks its tools first with command -v.
Secrets and .env Files (Journeyman): A secret such as a token or an API key never goes in a script: it goes in a .env file beside the project, which the script loads with set -a and source, which Git is told to ignore, and which chmod 600 keeps private to you.
Git Hooks: Scripts Git Runs for You (Freelancer): A Git hook is a script Git runs at a set moment: a pre-commit hook in .git/hooks runs before every commit, and when it ends with an exit code other than 0, the commit is stopped, so test.sh and ShellCheck run without anyone having to remember them.

Sharing Your Tool (Journeyman): A script someone else can use explains itself with --help and --version, comes with a README that says what it does and how to install it, an install script that puts it on their PATH, and a license that says what they may do with it, and GitHub is where people find it.
When to Reach for Another Language (Journeyman): Bash is at its best gluing programs, files and folders together on any Linux server or Mac; when a script needs real data handling, grows into many files of logic or has to run for Windows users, Python, JavaScript or C# fits better, and a bash script can hand the hard part to a program in one of them.

Exercise: A Project's Scripts (Journeyman): Give an animal shelter's website the scripts every project has: setup.sh checks the tools and makes a private .env, test.sh checks that every page has a title, and deploy.sh loads .env, runs the tests and copies the site with rsync; then keep .env out of Git, and let a check script tell you what's done.