Use clasp and Git for Apps Script

The Apps Script web editor is fine for a quick automation, but it has no real history, no branches, and no way to review a change before it ships. Its built-in “versions” are flat snapshots — you cannot diff them, comment on them, or roll back a single file. The moment more than one person touches a script, or the script matters enough to break carefully, that becomes a problem.

clasp — the Command Line Apps Script Projects tool — solves this by letting you keep the code on your own machine as ordinary files. Once the code is local, every tool you already use for software fits: Git for history and branches, your editor of choice, and pull requests for review. This guide covers the setup and the day-to-day workflow.

Setup

clasp is a Node package. Install it globally, authenticate once, then pull an existing project down:

# Install the clasp CLI globally (needs Node.js installed).
npm install -g @google/clasp

# Authenticate clasp against your Google account — opens a browser once.
clasp login

# Pull an existing Apps Script project into the current folder.
# Find SCRIPT_ID in the editor under Project Settings.
clasp clone SCRIPT_ID

clasp clone writes the script files locally plus a .clasp.json file that records which Apps Script project this folder is linked to. From here, treat the folder like any code project — run git init and make your first commit.

Workflow

The daily loop is: edit locally, commit to Git, push to Apps Script, test. Git and clasp are separate steps — one tracks history, the other syncs to Google.

# 1. Edit Code.js (and any other files) in your local editor.

# 2. Commit the change to Git — this is your real history.
git commit -am "Fix Stripe sync"

# 3. Push the local files up to the Apps Script project.
clasp push

# 4. Open the editor in a browser to run and test the script.
clasp open

Keep the two halves straight in your head: git commit records what changed and why, while clasp push makes that change live in Apps Script. A commit without a push leaves Google running old code; a push without a commit leaves you with no history of it.

Branching

Git branches give you isolation — work on a fix without disturbing the running script. The trick with Apps Script is that each branch can point at a different project.

.clasp.json is just a file in the repo, so it can differ per branch. Keep a dev branch whose .clasp.json targets a throwaway Apps Script project, and a main branch whose .clasp.json targets production. Switching branches then switches deployment targets automatically:

# On the dev branch, clasp push goes to the dev project.
git checkout dev
clasp push

# On main, the same command pushes to the production project.
git checkout main
clasp push

This means you can develop and test against real data in a sandbox, then merge and push to production only when the change is reviewed and ready.

Why bother

Moving Apps Script into Git is not ceremony — each capability removes a specific class of pain:

	Web editor only	clasp + Git
Change history	Flat, undiffable snapshots	Full commit log with messages
Code review	None	Pull requests with line comments
Branches	None	Isolated dev / prod / feature work
Rollback	Restore a whole version	Revert a single commit or file
Collaboration	Last save wins	Merges with conflict resolution

In short:

• Real diffs in review — a reviewer sees exactly which lines changed before the code ships.
• A record of who changed what and why — commit messages explain intent, which the editor never captures.
• Branches let you ship a fix cleanly — you can release a hotfix without dragging unfinished work along with it.

Common mistakes

• Forgetting to clasp push after committing. Git history says the bug is fixed, but the live script still runs the old code. Push is a separate, deliberate step.
• Editing in the web editor and locally at the same time. A clasp push overwrites whatever is in the project. Pick one source of truth — the local files — and clasp pull if a hotfix was made online.
• Committing .clasprc.json. This file holds your login credentials. Add it to .gitignore so you never push secrets to a shared repository.
• Pointing every branch at the production project. If .clasp.json is identical everywhere, branching gives you Git history but no deployment isolation — a dev push then lands in production.
• Treating clasp push as a release. Push only uploads files; the script still needs testing and, for web apps and add-ons, a fresh deployment. Pushing is not the same as shipping.