Repositories that live beside the stories they are for. Every change takes the same road, work branch to dev to stage to main, one pull request at a time, and nobody pushes to the branches that matter.
main, stage and dev are protected from the first commit. Work branches are named for their kind: feat/, fix/, hotfix/, chore/ and the rest.
$ squid clone https://squid.app/code/sample-app $ squid branch feat/invite-email $ squid commit -m "Send the invite email" 1 file changed $ squid push feat/invite-email → pushed (1 commit) $ squid env pull .env.local written: 6 values, secrets sealed
Squid keeps the code with the work: repositories with a file explorer, commits and line diffs, editing in the browser, and a small squid command to commit and push from your computer. There is no Git server to run.
Nobody pushes straight to main, stage or dev. Work happens on branches named for what they carry, feat/ or fix/, and moves one step at a time through pull requests: into dev, then stage, then main.
A repository is open to its project’s team, or private to its owner and the people given access. Each person is a writer or a guest who only reads.
Variables for development, staging and production, kept with the repository. Secrets are sealed and shown as dots; revealing or copying one is logged, never its value.
Your usual git and your editor’s git tools, with the same branch rules kept on every push.
Review a pull request line by line; protected branches need the approvals you set.
The pipeline runs on each new head, and the merge waits for green.
For teams that want the code flow first. Start with repositories and pull requests, and bring the backlog, sprints and the rest of Squid in when you are ready: everything you already have links up.