Roll out your first distribution

Run the first real rollout once the local checks pass.

If divekit doctor or divekit dev still report serious problems, fix them first.

If your setup already looks clear and you are working in a safe target group, continue to the real rollout.

Provide members

Distributed repositories usually belong to people. Divekit gives you two interactive ways to provide them:

1. Before the rollout with divekit members: an interactive prompt where you enter your member input. New input is merged with the members that are already configured.
2. During the rollout: if no members are configured yet, divekit distribute opens the same interactive member input before it creates anything.

Either way, Divekit stores the member input as a timestamped file in your user-level Divekit directory (~/.divekit/members/) — not inside the project — and references it from config.json through a members.path entry such as $DIVEKIT_MEMBERS/2026-07-16_10-24-55_M0_members.json. The permission level comes from members.permissions in config.json.

The member input also decides how many repositories are created: each line becomes one group, and each group gets exactly one generated repository. Two lines therefore produce two repositories.

A line with several comma-separated accounts, such as alice,bob, forms a team that shares one repository. Use plain GitLab usernames — no @ prefix, no email addresses.

If you already have a member list as a file, divekit distribute --members-file <path> skips the interactive member input. If members are configured as well, Divekit still asks what to do with them first.
Keep that file outside the project folder: everything inside the project is distributed, so a member list in the project root would end up in every generated repository.

For this first rollout you do not need a real course list: two lines with a safe test account are enough and give you two repositories to compare.
If you already entered members during the local validation run, they are still configured — the rollout will offer to keep them.

You can inspect the configured members at any time:

divekit members list -d M0

$ divekit members list -d M0

Members for M0

  source    $DIVEKIT_MEMBERS/2026-07-16_10-24-55_M0_members.json
  resolved  /home/your-name/.divekit/members/2026-07-16_10-24-55_M0_members.json

  b8520e99-2bad-c0de-b61c-1249a10f7a5a  student-one
  a70decaf-bad7-4c95-b211-d0bc95f48204  student-two

The resolved line shows where the member input actually lives on your machine, and each line below it maps one group UUID to its members.

Run the real distribution

Right before this step, some teams like to run one extra local preview with:

divekit distribute -d M0 --provider local

That can be useful when you want actual generated files before touching GitLab.

If M0 is your only distribution, you can simply run:

divekit distribute

If you want to be explicit, divekit distribute -d M0 is also fine.

This is the step where Divekit turns the prepared origin repository into individualized remote repositories.

What a healthy run looks like

$ divekit distribute -d M0

Configured members found. Choose action

●    Keep   Use 2 configured members
○    Add
○    Edit
○    Fresh

↑/↓ to navigate • enter to select • esc to cancel

┃  # Distribution Plan
┃
┃  https://gitlab.git.nrw/your-group
┃  └─ work
┃     ├─ M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a
┃     └─ M0-a70decaf-bad7-4c95-b211-d0bc95f48204

Proceed with distribution?

  Yes      No

Completed: 4/4

Distribution completed successfully!
Created repositories for 2 group(s)

Three things are worth reading in this flow:

• the Configured members found prompt appears because members are already configured — Keep uses them unchanged; if none were configured, the member input would open here instead
• the Distribution Plan is your last checkpoint before anything is created on GitLab: check the target group and the repository names before you confirm
• the final lines confirm how many groups received a repository

What happens during rollout

In a typical run, Divekit:

• reads .divekit/distributions/M0/config.json
• creates the target repositories
• individualizes the content
• assigns members and permissions
• writes state files

.divekit/distributions/M0/individuals.json
.divekit/distributions/M0/remotes.json

What success looks like

Run:

divekit overview -d M0

Then open the target GitLab group and confirm:

• repositories exist
• repository names follow the default pattern {{distribution}}-{{uuid}}, here M0-<uuid> — an optional name key in config.json could override that default
• the expected members were assigned
• the content differs where you expected variation

Example shape of a healthy overview:

$ divekit overview -d M0

From cache (2026-07-16 10:31)

b8520e99-2bad-c0de-b61c-1249a10f7a5a [student-one]
└─ work https://gitlab.git.nrw/projects/1234

a70decaf-bad7-4c95-b211-d0bc95f48204 [student-two]
└─ work https://gitlab.git.nrw/projects/1235

Each entry shows the UUID, the assigned members in brackets, and the created repository as a link.
The From cache (...) line means the member data comes from the cached members file — add --no-cache to fetch it fresh from GitLab.

If the UUIDs or repository names do not match what you expect here, stop and inspect before redistributing.

Quick interpretation

Common failures

Check

After the first real distribution:

1. run divekit overview -d M0
2. verify the created repositories in GitLab