Free vs Git Mode
PicaDeck supports two distinct workflows depending on your plan:
| Feature | Free (Auto-Save) | Pro/Team (Git Mode) |
|---|---|---|
| Save behavior | Changes save directly to the database automatically | Changes save to a draft, requiring explicit commits |
| Branches | Single branch only | Multiple branches for parallel work |
| Commits | Not available | Explicit commits with messages and snapshots |
| Pull requests | Not available | Full PR workflow with reviews |
| Version history | No snapshots | Immutable commit chain with full history |
Note
Branches
Branches let multiple team members work on different parts of the schema simultaneously without interfering with each other.
Every git-enabled project starts with a main branch. This is the primary branch that represents the current state of your schema. To experiment with changes or work on a feature, create a new branch:
- Navigate to the project's branch list
- Click Create Branch
- Give it a descriptive name (e.g., "add-user-preferences")
- Select the source branch to branch from (usually main)
Your new branch starts as an exact copy of the source branch. Any changes you make on this branch are isolated until you merge them back.
Branch naming
add-payment-tables, refactor-user-schema, feature/notifications.Making Commits
A commit captures a snapshot of your entire schema at a point in time, along with a message describing what changed. Commits create an immutable history that you can browse and revert to.
To make a commit:
- Make changes to your schema on a branch
- Click the Commit button in the floating toolbar (appears when you have uncommitted changes)
- Write a descriptive commit message
- Click Commit Changes
After committing, your draft is promoted to the branch's committed state and a snapshot is saved. The commit button disappears until you make more changes.
Write good commit messages
Viewing History
Every commit is recorded with its timestamp, author, message, and a full schema snapshot. You can view the commit history from the project's commit list to see how your schema has evolved over time.
The audit log also tracks all schema-related actions, providing a comprehensive trail of who changed what and when.
Pull Requests
Pull requests (PRs) are the mechanism for merging changes from one branch into another. They provide a review step before changes become part of the target branch.
To create a pull request:
- Make sure your branch has committed changes
- Navigate to the Pull Requests section
- Click Create Pull Request
- Select the source branch (your feature branch) and target branch (usually main)
- Add a title and description explaining the changes
- Submit the PR for review
Team members can review the PR, leave comments, and approve or request changes before the merge.
Merging
Once a pull request is approved and has no unresolved conflicts, it can be merged. Merging takes all committed changes from the source branch and applies them to the target branch.
After a successful merge:
- The target branch is updated with the merged schema
- A merge commit is created in the target branch
- The pull request is marked as merged
Conflict Resolution
Conflicts occur when the same entity (table, column, type, or relationship) has been modified in both the source and target branches since they diverged. PicaDeck automatically detects conflicts when you create or update a pull request.
When conflicts are detected, the PR is blocked from merging until they are resolved. You have three resolution strategies:
Accept Theirs (Source)
Use the changes from the source branch, overwriting the target's version for all conflicting entities.
Keep Ours (Target)
Keep the target branch's version and discard the source's conflicting changes.
Manual Resolution
Selectively choose which changes to keep for each conflicting entity. This gives you the most control over the final result.
Warning
Reverting Changes
If something goes wrong after a merge or commit, you can revert to restore the previous state:
- Revert a commit — restores the schema to the state before that specific commit
- Revert a merged PR — undoes a merged pull request by restoring the target branch to its pre-merge state
Reverts are safe: they create a new commit with the reverted state rather than deleting history. Your commit chain remains intact and you can always see what was reverted and when.