# Workspace management in Development

> How public and personal workspaces map to Git branches, and how to manage and refactor content across both.

## Introduction

Holistics organizes your BI content into two [workspace types](/docs/admin/permission-system#workspace-types):

- **Public workspace**: your company's shared dashboards, datasets, and models.
- **Personal workspace**: each member's private space for their own dashboards and experiments. Admins can browse everyone's personal workspaces through [Members' Spaces](/docs/admin/manage-users-personal-content) in Reporting.

Underneath, dashboards in both workspaces are code files under Git version control. For day-to-day work you never notice this: you create, edit, and delete dashboards directly in **Reporting**, and Holistics commits the changes to the underlying branch for you.

**Development** is for the work Reporting cannot handle: mass refactoring (say, renaming a metric that dozens of dashboards use) and other as-code workflows, for both workspaces. This page explains how each workspace maps to Git branches, and what that means when you refactor shared models.

## Workspaces and their branches

Each workspace is backed by its own set of Git branches. The table below shows what each branch does.

| Workspace          | Branch                                     | Role                                                                                                     |
| ------------------ | ------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| Public workspace   | `master`                                   | Production. What end users see in Reporting. Holds dashboards, datasets, and models.                       |
|                    | Dev branches (`user-a-dev`, `feat-b`, ...) | Make changes to the public workspace without affecting production. Publishing merges them into `master`.  |
| Personal workspace | `members-spaces/prod`                      | Live personal dashboards, exactly as members see them in Reporting. Read-only, dashboards only.            |
|                    | `members-spaces/dev`                       | Edit personal dashboards in Development. Publishing merges into `members-spaces/prod`.                     |

The diagram below shows how the branches relate. Publishing a normal dev branch merges it into `master`. Publishing `members-spaces/dev` merges it into `members-spaces/prod`. Reporting reads from both sides: public dashboards come from `master`, and personal dashboards come from `members-spaces/prod`.

<ReactFlowDiagram id="workspace-branches" height={460} />

Branching and [publishing](/docs/development/dev-prod-mode) follow the standard [Git workflow](/docs/git-version-control/) in Holistics. If your branch is behind `master` when you publish, Holistics pulls `master` into it first, then merges. See [Branch management](/docs/git-version-control/branch-management) for creating and deleting branches.

The `members-spaces` branches contain only dashboards. The datasets and models those dashboards use live on `master`, and personal dashboards read from it directly. When you publish, they pick up the new production code right away, with no merge step in between.

## Refactoring across workspaces

Mass refactoring (renaming a metric, deleting a field, renaming a model) happens in Development on a development branch. Because public and personal dashboards live on different branches, you fix them at different points. The diagram below shows the full flow, and the two sections after it cover each half.

<ReactFlowDiagram id="refactor-flow" height={320} />

### Fix public dashboards before you publish

Public dashboards live on the same code base as your models. If your refactor breaks one of them, you see the syntax error right away on your development branch. Fix every affected dashboard there and publish everything together, so nothing broken reaches production.

### Fix personal dashboards after you publish

Personal dashboards live on the `members-spaces` branches, so your development branch cannot touch them. You fix them right after publishing:

1. Publish your development branch to `master`.
2. Personal dashboards that used the renamed or deleted field now break, because `members-spaces/prod` reads directly from `master`. This short broken window is expected.
3. In Development, check out the `members-spaces/dev` branch.
4. Fix the broken dashboards. The same syntax errors show up there.
5. Publish. Your fixes merge into `members-spaces/prod`, and the dashboards work again in Reporting.

:::info
You cannot fix personal dashboards before publishing because they live on separate branches. Your refactor only reaches them once it lands on `master`.
:::

## Why personal dashboards are isolated

Keeping personal workspaces out of the publish workflow is a deliberate choice. A member's experimental dashboard can never block a production publish, and unreviewed content never lands on `master`.

The trade-off is the short broken window after a refactor, until you fix personal dashboards on `members-spaces/dev`. Keep anything your team depends on in the public workspace, where every publish validates it.

## FAQs

#### What happens when I publish from a dev branch to master?

Three things, in order:

1. Holistics merges your branch into `master`, pulling `master` into it first if it is behind. The changes go live for the public workspace.
2. The `members-spaces` branches record the new `master` reference. You will see this as an "Update public_workspace..." commit on them.
3. Personal dashboards now read the new production code. If your publish renamed or deleted something they use, they break at this point. Fix them on `members-spaces/dev`, as described in [Fix personal dashboards after you publish](#fix-personal-dashboards-after-you-publish).