All articles

Workflow / Field notes

Scale Grasshopper Workflows with GitHub

Use version control and better workflow habits when Grasshopper projects become larger and more collaborative.

Marijn Luijmes2 min readCompanion to the video of

When a Grasshopper definition becomes part of a team's project infrastructure, saving another copy is no longer enough. People need to know what changed, which version works and why a decision was made. This video considers how GitHub and version-control habits can support that shift.

Try it yourself

Get the template in the community

Templates are hosted in Ontologic Academy on Circle. Follow the link, then sign in or create a community account to access the template and its instructions.

Make a change understandable

A useful saved version represents a coherent change with a short explanation. Describe the behavior that changed and the reason for it, rather than relying on a filename to carry the history. This helps a future teammate distinguish a deliberate revision from an experiment.

The editor shows a side-by-side change comparison for the code behind the workflow.
Reviewing a code change with a visible diffThe editor shows a side-by-side change comparison for the code behind the workflow.Watch this moment at 0:27

Version control can preserve files, but it does not automatically make visual definitions easy to compare or merge. Be realistic about the file formats involved. Clear ownership and smaller, well-scoped changes remain valuable even when a graphical change cannot be reviewed like ordinary source code.

The code editor exposes the Python files and implementation used by the model.
Organizing reusable geometry logic in a repositoryThe code editor exposes the Python files and implementation used by the model.Watch this moment at 1:01

Document the environment

A definition may rely on plugins, external files or particular input conventions. Record those dependencies alongside the workflow. Otherwise an older version may exist in the repository without being reproducible on another machine.

The floor-plate example is shown beside the local and remote loading workflows.
Separating local and remote code pathsThe floor-plate example is shown beside the local and remote loading workflows.Watch this moment at 0:48

Include a minimal example and explain how to recognize a successful output. A teammate should be able to open the project, supply the expected inputs and understand whether it is behaving correctly without reconstructing the original author's process.

A generated floor assembly is visible beside the component that reads the code.
Connecting reusable code to the Grasshopper definitionA generated floor assembly is visible beside the component that reads the code.Watch this moment at 1:22

Use collaboration deliberately

Issues can capture problems and planned improvements, while a review process gives changes a place to be discussed. Choose a workflow proportionate to the team. The goal is a dependable shared system with a recoverable history, rather than additional process that nobody maintains.

The repository editor provides the context for the discussion of pushing changes to the cloud.
Keeping reusable code in a shared repositoryThe repository editor provides the context for the discussion of pushing changes to the cloud.Watch this moment at 2:23

From concept to canvas

See the workflow in practice

The companion video shows the model and the workflow behind these ideas. Watch the walkthrough when you want to see how the pieces connect.

Watch on YouTube