Base Snapshot Selection Strategy - Git vs Visual Git

Choose the right base snapshot selection strategy for your visual test workflow.

Percy’s base snapshot selection strategies enable you to choose the appropriate baseline for comparison. This simplifies the process of decision making for the visual changes detected within your application.

Percy supports two base snapshot selection strategies:

• Git
• Visual Git

How it works?

To find the right base snapshot for comparison, you need to select the baseline management strategy during project creation.

Git

The Git strategy works like Git-based branching comparisons when code changes in a branch are merged with the main or production branch. In this case, Percy relies on Git commit information to find the right base build. Select the Git strategy, if you are a developer. To know more, read Base build selection.

The following diagram shows how the base build is selected with this strategy:

Git Strategy Example:

Developers handle releases using a full CI/CD setup.

Developer A works on a new feature in a dedicated branch. They create 10 builds during development and compare changes against the current production version using the Git strategy. Once development is finished, they initiate a PR to merge into the main branch. CI/CD conducts functional and visual checks. If successful, changes deploy to Production.

Visual Git

Visual Git is a specially designed visual version control system, where Percy does not rely on Git commit information. In Visual Git, every branch gets its own branch level baseline that has the latest approved snapshots for visual comparisons.

If you are a QA, SDET, Designer, or other persona responsible for visual testing, select the Visual Git strategy.

The following diagram shows how Visual Git works:

Visual Git Strategy Example:

QA/SDET are responsible for release with complete CI/CD setup in place, where as developers co-share the responsibility.

Developer A works on a new feature in a dedicated branch. They create 10 builds during development and compare changes against the current production version using the Git strategy. Once development is finished, they initiate a PR to merge into the staging environment. The QA team handles regression testing and proceeds with releases only when everything clears the tests.

During visual regression, the QA team employs the Visual Git strategy to test the changes against the previous production release. This involves comparing against the latest approved snapshots in the main or base branch as per the project configurations.

When to choose what strategy?

If your answer to the following questions is yes, then choose Git:

• Do you work on multiple feature branches, which generally need to be compared against the main branch?
• Do you look for comparison against base branch which is main?
• Do you work with approvals or rejections at the build level?

If your answer to the following questions is yes, then choose Visual Git:

• Do you work with approvals or rejections at the snapshot level?
• Do you want comparisons against latest approved snapshot only?
• Do you want to perform your visual testing outside/independently of the development pipeline?

Select the baseline management strategy

To select the baseline management strategy, follow these steps:

1. Visit https://percy.io/
2. Go to dashboard & click “Create new project”.
3. Select Web as the platform.
4. Select GitorVisual Git as a baseline management strategy.

Change the baseline management strategy

To change the baseline management strategy, follow these steps:

1. Select the Percy project for which you want to change the baseline management strategy.
2. On the Project settings page, go to the Baseline management option and toggle the required option.

Project settings page section for reference: