Welcome and mental model

Start with the beginner workflow model that the rest of the course will reuse.

Divekit starts from one local source repository and creates individualized remote repositories from it.

You will build this project structure step by step later in the course.
At this point, it is only a mental model, not a task to create these files already.

A simplified view looks like this:

vehicle-workshop/
├── .divekit/
│   ├── individualization.json
│   └── distributions/
│       └── M0/
│           └── config.json
├── src/
│   └── $Vehicle$.java
└── README.md

The most important idea is this:

• your origin repository is the source
• your distribution is one named rollout setup inside that repository
• your individualization file describes what may vary across the generated repositories

Origin repository

The origin repository is the local source repository that contains your assignment template and Divekit configuration.

Divekit itself does not need git: it talks to GitLab through its API, so a plain local folder is enough for this course.
Keeping the project in git is still good practice — Divekit then respects your .gitignore during distribution, for example.

Distribution

A distribution is one named setup inside .divekit/distributions/<name>/.

It contains the configuration for one rollout. In this course, we will use the distribution name M0.

Individualization file

For this course, the key file is individualization.json.

It defines what may vary across distributed repositories.

For the beginner workflow, you only use its variation section.
The rest of the file can stay minimal because Divekit already has sensible defaults.

Example idea:

• repository A gets Car
• repository B gets Bike
• repository C gets Plane

Workflow

For this course, the workflow is:

1. install Divekit
2. configure a GitLab host and token
3. create or enter your project folder
4. run divekit init
5. review the generated config.json
6. check unresolved placeholders with divekit dev, then scaffold them with divekit dev --write-individualization
7. review or refine individualization.json
8. validate the setup locally
9. provide members with divekit members, or enter them when a distribution run asks — the optional local validation in step 8 already counts
10. run the real rollout with divekit distribute
11. inspect the generated state afterwards

You can practice all of this safely: nothing is created on GitLab before step 10.
doctor, the dev scan, and --provider local stay on your machine — and divekit purge can remove test repositories again afterwards.

Example

We will use a small example assignment called vehicle-workshop.

It is intentionally minimal:

• one placeholder: $Vehicle$
• one distribution: M0
• one simple variation object: Vehicle
• a few possible replacements like Car, Bike, and Plane

This keeps the course focused on the workflow instead of domain complexity.

Check

Before moving on, make sure you can answer these questions: