A commit is a saved version of a workflow: a snapshot of everything in it at one moment, captured so you can look back at it, return to it, or build on it. Commits are how Tines 3B keeps a history of your work, so editing a workflow never means losing what came before.
A snapshot of the whole workflow
Each commit captures the complete state of a workflow: every step, its code, its configuration, and its readme, exactly as they were when the commit was made. It's not a diff or a partial change; it's the full picture. That's what lets a commit stand on its own as a version you can view or restore in its entirety.
Snapshots are cheap because Tines 3B stores each file once and lets commits share the files they have in common, so keeping a long history doesn't mean keeping many full copies of everything.
Commits form a history
Commits don't sit in isolation. Each one points back to the commit it came from, so together they form a chain: the workflow's history, in order. That chain lives on a branch, and the branch's most recent commit is its current state, the version you see and edit.
Make a change and the branch moves forward to a new commit; the earlier ones stay behind as the record of how the workflow got here.
Checkpoints you can return to
Not every commit is a milestone. As you work, the current version is a live, in-progress snapshot that keeps updating. When a change is worth marking, it becomes a checkpoint: a commit with a name describing what it captured. Checkpoints are the meaningful points in the history, the versions you'd actually want to find and go back to, as opposed to the moment-to-moment working state.
This distinction is what makes the history readable. Instead of a wall of tiny saves, you get a timeline of named versions that tell the story of the workflow.
Restoring an earlier version
Because every checkpoint is a complete snapshot, you can restore a workflow to one. Restoring doesn't erase what came after; it brings the old version's files forward as a new commit at the top of the history, and it preserves the state you were on so you can undo the restore if you change your mind. Going back is just another step forward in the history, which means it's always safe to try.
Going live is a commit
Publishing a workflow is a commit too. When you push a draft live, Tines 3B records a new commit on the main line with a message describing the change, carrying the draft's files and the conversation that produced them. So the live version of a workflow is simply its latest commit on the main branch, and its history is the trail of everything that's been published.
A run, in turn, is pinned to the exact commit it ran against, which is why looking back at a run shows you the workflow as it truly was at that moment, not as it looks today.
Tied to how it was made
Each commit is linked to the chat that created it, the back-and-forth with Tines 3B that produced the change. That keeps the why attached to the what: a version in the history isn't just a set of files, it's paired with the reasoning and the requests that shaped it.
When a workflow syncs to a git repository, these commits map onto git commits, so the same history travels with the code outside Tines 3B.