Most people use SnipShare the same way they used Pastebin: create a paste, share the URL, done. That covers the immediate sharing need but misses the tools that make SnipShare useful for ongoing work - forking and revision history.
Forking lets someone take your paste and iterate on it without modifying the original. Revision history gives you a full audit trail of every change you make, with a side-by-side diff between any two versions. Together they handle the workflows that a static share does not: collaborative improvement, tutorial versioning, client handoff, and code review over async channels.
What forking actually does
When you fork a paste, SnipShare:
- Creates a new paste owned by you with the same file content.
- Records the fork relationship - the fork shows which paste it was forked from, and the original paste shows how many times it has been forked.
- Gives the fork its own URL, its own revision history, and its own visibility settings.
The original paste is not modified. The fork is completely independent from the moment it is created.
This is the same model as GitHub Gist forking, and the mental model carries over: fork when you want to iterate on someone else’s work, or when you want to create a variant that diverges from the original.
Three workflows where forking is the right tool
Tutorial versioning for educators
If you write tutorials with code examples, forking solves the version-sprawl problem. The workflow:
- Publish the starting code as a paste (the state students begin with).
- Fork it to create the finished version (the state they are working toward).
- Fork the finished version again for each common variation or alternative approach.
Readers who want to see the diff between the starting and finished state use the Compare tool on any two revisions. You link to the right paste version in the tutorial body.
When the tutorial needs updating for a new framework version, fork the current version rather than editing it in place. Old links continue to work. New readers get the current version. You have a clean history of what changed between versions.
Client code handoff
Sharing code with clients during a project is where the Unlisted + fork combination is useful. The workflow:
- Create the initial code as an Unlisted paste. Send the URL to the client.
- When the client has questions or requests changes, they fork the paste and annotate it (or just describe what they want, and you fork it).
- Each iteration has its own URL and its own revision history.
- The client always has access to the version you shared with them, even as you continue iterating.
The fork chain gives you a record of the full collaboration - what you sent, what changed, what the client received at each stage. This is harder to reconstruct from a series of email attachments or Slack message edits.
Team code review without a PR
For small teams reviewing scripts, configs, or code snippets that do not live in a version-controlled repo, the fork + revision approach handles the “how do we review this” question:
- Author creates the paste.
- Reviewer forks it and makes suggested changes to the fork.
- Author uses the Compare tool to diff the reviewer’s fork against the original.
- Author accepts the changes by updating the original paste (or creating a new revision incorporating the changes).
This is not a replacement for GitHub pull requests on production code. It is a lightweight alternative for the category of code that does not have a home in a repo - runbook commands, one-off scripts, configuration snippets, SQL queries.
How revision history works
Every time you edit and save a paste, SnipShare creates a new revision. The revision log is available from the Revisions tab on any paste view.
The log shows:
- Timestamp of each save
- Which file was changed (in a multi-file paste)
- The number of lines added and removed
Click any two revisions and hit Compare to see the diff. The diff view shows:
- Added lines in green
- Removed lines in red
- Unchanged lines for context
- Per-file diff when multiple files changed in the same revision
You can compare any two revisions, not just adjacent ones. If you want to see what changed between the initial version and the current state, select the first revision and the most recent one.
Revision history use cases
Iterating on a script over several sessions. You work on a deployment script across three work sessions. The revision log tracks what you changed each time, without needing a git repository for a single script.
Identifying when a regression was introduced. A configuration snippet worked last week and does not work today. The revision log shows what changed between the working version and the current one.
Documenting what you tried. During debugging, you iterate through several approaches to a problem. Each save creates a revision. After you find the fix, the revision history documents what you tried before you got there - useful for writing the postmortem or explaining the approach to a teammate.
Comparing revisions - step by step
- Open any paste you own and click the Revisions tab.
- You see a list of revisions with timestamps.
- Check the box next to two revisions you want to compare.
- Click Compare selected.
- The diff view opens. For multi-file pastes, each file with changes has its own diff block.
To share a specific revision with someone, the revision URL is stable - it points to the paste state at that exact save, not the current version. Useful for sending someone “what the code looked like before I changed it.”
Quick reference: fork vs. revision
| Action | When to use |
|---|---|
| Fork | You want to create an independent variant; you want to iterate on someone else’s paste; you want to propose changes without touching the original |
| New revision | You are continuing to work on your own paste; iterative improvement on the same file; fixing a bug in your own code |
| Compare revisions | Audit trail between two states of your own paste |
| Compare fork to original | See what changed between your variant and the source |
The two tools cover different needs. Revision history is the audit trail within your own work. Forking is the collaboration layer across different people or use cases.
Getting more from the archive
All public pastes (and your own private pastes) are searchable from the /pastes/ archive. You can filter by:
- Language (shows only JavaScript pastes, only SQL, etc.)
- Tag (if you tagged the paste on creation)
- Author (your own pastes, or another user’s public pastes)
Tagging consistently at creation time - even just a one-word topic like “deploy” or “sql” or “nginx” - pays off when you have 50 pastes and need to find the right one fast. The tag filter is a lot faster than free-text search on a large personal library.
The fork and revision features are worth building into your workflow from the start, even if the immediate need is just “share this snippet.” The revision log starts accumulating from the first save. When you need it - for a diff, for a rollback, for a handoff - the history is already there.