Review and integrate changes
Read the three numbers of your working copy, make a checkpoint, bring in what others integrated, review the diff, the verification and the conflicts, and integrate. Integration is not publication, and there is no Publish action.
- Availability: Experimental
- Evidence: Recorded run
- How-to guide
Before you start
- Your environment must be running: the repository is read where your working copy is.
- Checkpoint, update and integrate need a role that can write: Owner, Administrator or Developer. A Viewer reads the state, under the line "Your role cannot checkpoint or integrate. The state below is for reading."
Three numbers
Review starts with Your working copy and your branch. It keeps three things apart:
| Number | Meaning |
|---|---|
| Saved, not committed | Files saved in your environment and not yet in a checkpoint |
| Committed, not integrated | Checkpoints on your branch that the project does not have |
| Integrated by others | Work the project has and your branch lacks |
Workspace explains the levels in one line: "Saved files live in your environment’s storage. A checkpoint commits them to your branch. Integrating shares them with the project."
Each person works on a branch of their own. The project has one shared branch, and only integration writes to it.
Checkpoint
Checkpoint commits everything saved to your branch only and keeps a copy of that branch outside your environment, which is what survives the loss of the environment's storage. Nobody else receives anything.
A checkpoint is also made for you before your environment stops, before an update and before an integration. Nothing integrates by itself.
Bring in integrated work
Bring in integrated work merges what others integrated into your branch. If it would conflict, it is rejected and nothing changes.
Review before integrating
Choose Review before integrating. It changes nothing; it shows what an integration would do:
| Part | What it shows |
|---|---|
| Changes to integrate | The difference between your working copy, uncommitted work included, and the shared branch. With none: "There is nothing to integrate." |
| Verification | "Verification passed: the working copy builds", "Verification failed: the working copy does not build" or "Verification unavailable: the build state could not be read" |
| "Conflicts with the shared branch:" and their number | The files an integration would conflict on |
Under the verification: "This is shown so you can decide. It does not block integration." Review again repeats it after you change something.
Integrate
Integrate changes shares your committed work with the shared branch of the project. Anyone who can write integrates: there is no mandatory approval by another person.
| Outcome | Meaning |
|---|---|
| "Integration completed" | The shared branch has your work |
| "Integration: nothing to do" | You have nothing of your own to integrate, even if you are behind |
| "Integration rejected. Nothing changed." | Conflicts are decided before anything is touched. On a conflict (MERGE_CONFLICT) there is no checkpoint, no merge, no changed file and no change to the shared branch, and Workspace says "Your work and the shared branch changed the same lines. Bring in the integrated work, resolve the files, then integrate again." When someone integrated in the same instant (NON_FAST_FORWARD): "The shared branch moved while this ran. Review again and integrate." |
| "Integration failed" | It did not complete; the reason is shown |
The shared branch is only ever moved forward. It is never forced.
Integration is not publication
Workspace says it above the button: "Integration shares your committed work with the project’s shared branch. It is not publication."
Integrating makes your code part of the project for your colleagues. It publishes nothing, releases nothing and deploys nothing, and there is no Publish action in Workspace or in Projects. Releases of an application are prepared and promoted through the CDN. Preview, integration and publication are different things explains the three.
Limits
- The project's repository is kept by the installation itself. No hosted Git provider is connected, and nothing pushes to one.
- With the environment stopped, Review says "Start the environment to see your working copy": "Git runs inside your environment, so its state and the integration review exist only while it runs. Nothing is lost: stopping checkpointed your saved work on your branch."
- Two instances of the service integrating one project at the same moment were not part of the recorded runs.