Branches and baselines
Chromatic understands Git. Once a snapshot is accepted in Chromatic, it won’t need to be re-accepted until it changes, even through git branches, and merges.
Baselines are intelligently choosen based on your git history in the way you would expect. No configuration necessary.
Chromatic compares snapshots to a baseline: the last known “good” state of the story.
Each story has its own baseline that is tracked independently each branch. When you approve a snapshot you also update the baseline for that story.
Chromatic uses the branch that is checked out when you run a build to mark builds in our system. This means it is easy to see which builds belong to which branch of development, which components exist and are tested in which branch, and how a component has changed over the history of a branch.
When you are developing in a branch, it is natural that the baseline image should be chosen from previous commits on the branch. This means if your team is developing on multiple branches in parallel, changes to the approved component screenshots on one branch will not affect the others.
When you merge two branches together, Chromatic can sometimes have two (or more) potential screenshots to use as the baseline (one from each branch). In such situations, Chromatic will choose the most recent approved change as the baseline.
If you rebase a branch (say updating to branch off the latest commit off
master), then you create a new commit that isn’t a git descendent of the previous (pre-rebase) commit on that branch. Conceptually, that might mean that Chromatic should throw away any approvals that were made for builds on the branch, however this is probably not what you want.
For this reason, we always include approvals from the latest build on the current branch, regardless of git history. You can bypass this with the
--ignore-last-build-on-branch=<branch-name> flag of