Skip to main content
Honeydew leverages a Git development workflow to store and manage changes to all semantic layer metadata, backed by a Git repository providing version control. The Git repository can be either provided and managed by the customer, within their Git provider of choice, or hosted by Honeydew. The metadata is stored within the Git repository in an open format (YAML).
Metadata YAML files can be directly edited in any external editor, not just by using the Honeydew Studio UI

​
Git Provider Integration

Honeydew supports integration with all major Git providers. Choose your preferred provider for detailed setup instructions:

​
Git Repository Structure

Different workspaces reside within the same repository as separate folders, each containing their separate semantic layer metadata, environment settings and more.

​
Repository Structure

Each workspace folder contains:
  • schema/: All entities, each with its attributes, metrics, and datasets
  • domains/: Domain configurations and settings
  • perspectives/: Dynamic datasets, including pre-aggregates
  • workspace.yml: Workspace-level settings and configurations, including environments settings
Different workspaces within an organization can share the same Git repository, but maintain complete semantic separation through folder isolation

​
Git-Based Development Workflow

​
Branch-Based Development

Changes in Honeydew are made over branches in Git, following standard development practices:
  1. Branches:
    • Users work on branches for their changes
    • Branches in Git are automatically created when a user creates a new branch for making changes in Honeydew Studio
    • Changes within a branch that are done in Honeydew Studio UI, are scoped to a specific workspace and do not affect other workspaces
    • Branches are shared across all users within a workspace, allowing any user to access and collaborate on any branch
    • Each Honeydew branch maps to a Git branch named <workspace>/<branch> — for example, branch q3-fixes of workspace sales is stored on the Git branch sales/q3-fixes. The prod version of every workspace lives on the repository’s default branch. CI/CD tools use this convention to detect which workspace and branch a change belongs to (see the CI/CD Overview)
  2. Discarding Changes: At any time, users can discard a branch with all the changes that were made in it
  3. Production Publishing:
    • When users click Publish changes in Honeydew Studio UI, a Pull/Merge Request is automatically created in the Git repository, from the underlying Git branch to the main Git branch.
    • Users can review all the changes they have performed, before publishing.
  4. Merging: Two workflows are supported, as two actions in the Publish changes dialog:
    • The Pull/Merge Request is automatically merged after creation, using the Publish action (recommended for evaluation period and small teams)
    • The Pull/Merge Request requires manual review and approval before merging, using the Create Pull Request action (recommended for production workflows)
    Currently there is no way to configure automatic/manual merging permission per user or per branch. This functionality is coming soon.
    Once merged, the prod version is updated with the new changes and becomes the new shared source of truth for all users and tools that use the semantic model represented by the workspace.
In some cases you would want to manually review and merge Pull/Merge Requests, and not allow automatic merging at any circumstance. This can be achieved by setting branch protection rules in your Git provider to require mandatory review and approval for any Pull/Merge Requests, before merging to the main branch.Additional fine-grained rules, such as requiring named approvers for a specific workspace or for specific entities/metrics, can be configured at Git provider level, using required reviewer rules, the Code Owners functionality, or other branch protection policies.See Change Approval for step-by-step instructions on requiring approval from specific people for changes to a specific workspace.

​
Branch cleanup after merge

The branch list in Honeydew Studio reflects the branches that exist in the Git repository, so deleting a Git branch also removes that branch from Honeydew. When a Pull/Merge Request is merged in the Git provider rather than in Honeydew Studio, nothing deletes the underlying branch, and merged branches accumulate in the branch list. Configure your Git provider to delete the source branch on merge to clean them up:
This covers only branches that were merged through a Pull/Merge Request. Branches that were never published, and branches whose Pull/Merge Request was closed without merging, still need to be discarded in Honeydew Studio.
Honeydew caches the branch list, and changes made directly in Git — including branches deleted by your Git provider on merge, or deleted manually — do not refresh it on their own.To refresh it in Honeydew Studio, open the workspace menu and select Reload current Workspace for all users.From a pipeline, use the Reload All Workspaces mutation (GraphQL) or RELOAD_ALL_WORKSPACES in the Snowflake Native App. These refresh the branch list for the calling user only — to refresh it for everyone, use the for All Users variants, such as RELOAD_ALL_WORKSPACES_FOR_ALL_USERS.

​
Changes history

All changes to the semantic layer metadata are tracked in Git, providing a complete history of every modification. Users can view the history of changes, compare different versions, and revert to previous states if needed.
Currently, reverting changes must be done outside of Honeydew Studio UI, by reverting the relevant commits in Git. Reverting changes from within Honeydew Studio UI is coming soon.

​
Collaboration Features

Honeydew provides real-time collaboration capabilities through shared branch access:
  • Shared Branch Access: Any user can access and work on any branch created by other users, enabling collaborative development on features or analyses
  • Branch-based Collaboration: Teams can create branches for collaborative projects, with multiple users contributing changes to the same branch
  • Change Detection: When other users publish changes to prod, branches that do not yet contain those changes show an Out of sync indicator next to the branch name
  • Branch Refresh: Clicking Out of sync and choosing Update rebases the branch on the current prod (see the FAQ)
  • Conflict Resolution: Honeydew Studio does not provide any dedicate tools for conflict resolution. Standard Git workflows apply for resolving conflicts within any yaml files.
Since Honeydew stores each entity, attribute, metric, dataset, and domain as separate YAML files, the chances of merge conflicts are significantly reduced, even with multiple users working concurrently.

​
Development Workflows

Development flows outside of Honeydew Studio UI can operate directly on the Git repository.

​
Edit files directly

The following use cases can benefit from using a code editor directly on files in the Git repository:
  • Major Refactoring: Large-scale changes can be performed by editing the semantic layer YAML files directly
  • Bulk Operations: Mass updates across multiple entities, metrics, or attributes
  • Automation: Script-based metadata management and deployment
You can run validations on changes in the Git repository by using the Honeydew Snowflake Native Application - you can find an example here.

​
Use with your Git provider capabilities

  • Code Review: Honeydew creates Pull/Merge Requests that can be reviewed within your Git provider UI
  • CI/CD Pipelines: Use Git provider CI/CD capabilities to validate, deploy, and publish semantic layer changes automatically. See the CI/CD Overview for the full workflow, or the GitHub Action to validate pull requests on GitHub
  • Complex conflict resolution: Use your Git tools to handle complex merge conflicts if they happen

​
FAQ

​
What happens when I publish after someone else published changes?

Your branch keeps the model it had, and shows an Out of sync indicator next to its name. Before publishing, click Out of sync and choose Update. Honeydew rebases your branch on the current prod, so you can validate your changes against the latest model before they reach prod. Then publish as usual. If you publish without updating, Honeydew merges your branch as long as your changes do not overlap with the new prod changes. If you and the other user changed the same part of an object’s YAML file, Update fails with “Resolve your conflicts manually”, and publishing fails with “unable to merge”. Resolve the conflict with standard Git tools:
  1. Clone the repository and check out the Git branch <workspace>/<branch>
  2. Rebase it on the default branch and resolve the conflicts in the affected YAML files
  3. Push the branch with git push --force-with-lease
  4. In Honeydew Studio, open the workspace menu and select Reload current Workspace for all users

​
In which order should I publish several branches with changes?

Every branch is created from prod, so branches are independent of each other and can be published in any order. When one branch holds a small change that is ready and another holds larger work still in progress, publish the small one first, so it reaches prod without waiting for the larger work. After publishing the first branch, the remaining branches show Out of sync. Update each one before continuing to work on it, as described in the previous question. If two branches changed the same part of a file, updating the second one fails with a conflict, which you resolve the same way. Publishing with Publish deletes the branch once it is merged and switches you back to prod. Publishing with Create Pull Request keeps the branch until the request is merged in your Git provider (see branch cleanup after merge).